Re: Auth 2.0 spec errata regarding delegation vs. directed identity
On Wed, May 14, 2008 at 11:20 AM, Martin Atkins [EMAIL PROTECTED] wrote: * The RP, when verifying that the openid.claimed_id URL in the assertion is valid, checks only that the openid2.provider value is correct, and doesn't check that the openid2.local_id value matches (after removing the fragment part) the openid2.identity URL. [...] Both of the above are currently allowed by the Auth 2.0 spec, but since doing the above checks doesn't seem to remove any useful possibilities, I think there ought to be some sort of errata that requires the checks I've listed above. The Verifying Discovered Information section[1] of the OpenID 2.0 Authentication spec is actually pretty explicit about the fact that the relying party needs to verify this: If the Claimed Identifier is included in the assertion, it MUST have been discovered by the Relying Party and the information in the assertion MUST be present in the discovered information. It then goes on to list the information that must be verified. I think this is already covered. Josh http://openid.net/specs/openid-authentication-2_0.html#verify_disco ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Auth 2.0 spec errata regarding delegation vs. directed identity
On Wed, May 21, 2008 at 1:03 PM, John Ehn [EMAIL PROTECTED] wrote: I'm tending to agree with Martin on this one. I guess that statement does, in a roundabout way, implies the Relying Party should do the following: This is probably because I'm so familiar with the protocol and the spec, but I'm not sure what exactly you're asking for. That section of the spec lists the fields in the discovered information that must be matched against the OpenID id_res response and what to match them against. I don't see the ambiguity. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Errata (was Re: openid:Delegate undefined namespace)
We failed to update the spec to include the OpenID 1.1 XML namespace for XRDS discovery. We should create an errata document for the OpenID 2.0 spec on openid.net and add this information. On Dec 3, 2007 9:56 PM, Manger, James H [EMAIL PROTECTED] wrote: Section 14.2.1 Relying Parties (discussing compatibility with OpenID 1.1) says: the end user's OP-Local Identifier appears in the openid:Delegate tag However, the namespace URI associated with the openid namespace prefix is not defined. I guess it should be http://openid.net/xmlns/1.0;, which needs to be mentioned in the spec. Change openid:Delegate in the 2nd dot point in 14.2.1 to Delegate xmlns='http://openid.net/xmlns/1.0' ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Adding fields to SREG (was: Re: SREG namespace URI rollback)
On 11/1/07, David Recordon [EMAIL PROTECTED] wrote: Sorry it took me a few days, but seems alright to me. I think a larger question would be if there should be any material differences with SREG 1.1 such as adding a few additional common fields. -1 on adding anything to SREG; that's what Attribute Exchange is for. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: HMAC-256 vs HMAC-SHA256 for openid.assoc_type
On 10/30/07, Manger, James H [EMAIL PROTECTED] wrote: It was HMAC-SHA256 in draft 9 (10 Sep 2007), but had changed to HMAC-256 in draft 10 (13 Oct 2007). The change is looking more like a typo. Indeed, this is an error in the text. It's intended to be HMAC-SHA256. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 2.0 finalization progress
On 10/22/07, Gabe Wachob [EMAIL PROTECTED] wrote: 3) the community calls the spec final and a contributor raises a potential patent infringement issue, and since the community has already implemented and deployed 2.0, the patent owner has more leverage because the costs of engineering around the claims in the patent have gone way up because of already-deployed software. In order for this to be a concern, there needs to be a party who currently: 1. has a patent that the spec infringes upon -- and -- 2. intends to claim infringement it if the spec is released without an IPR agreement in place -- and -- 3. would be party to the IPR agreement Did I get this right? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Announce: OpenID Authentication Draft 12 (finally)
Hello OpenID community, I'm happy to announce draft 12 of the OpenID Authentication 2.0 specification [1]. It's been a long time [2] since the previous draft, and it's past time that we get the work that has been done out, so that users and developers can benefit from OpenID 2.0. In the next month, we'd like to see implementers update their libraries or applications to be draft 12 compliant and perform interoperability testing. Once this period is over (October 1st), we should call the specification final, pending final IPR clearance from contributors. If we have IPR clearance by that point, we can call the spec final on October 1st. In the past, we've had timelines proposed and slipped. I don't think there's any reason for that to happen in this case, and I hope that the community will hold the editors accountable. Let's get this done! Josh Hoyt [EMAIL PROTECTED] OpenID: http://j3h.us/ 1. http://openid.net/specs/openid-authentication-2_0-12.html 2. http://openid.net/pipermail/specs/2007-January/001155.html 3. Major changes to the OpenID authentication specification, draft 11 to draft 12: * Specify handling of URL fragments * Realm verification using XRDS discovery * Don't allow unencrypted secret exchange unless operating with transport layer encryption ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier recycling write-up on the wiki
On 6/20/07, Chris Drake [EMAIL PROTECTED] wrote: You've got 6 points under the use cases, but it's really just 1 use case, and then 5 consequences [of] recycling. I was trying to precisely define the identifier recycling problem to which people are discussing a solution. Feel free to correct the structure if you have a better presentation, or to add more depth to the problem description. Is there room on your Wiki for opposition? It's only going to take one screwup and an angry victim someplace and the whole recycling issue could bankrupt someone in the prevailing identity theft lawsuit. There is certainly room for opposition, but I tried to frame this issue with a minimum of bias, and I hope that anyone who contributes to the wiki will try to do the same. That is, I encourage you to add or correct anything that's there (it's a wiki, after all), but please add a section arguments against identifier recycling or similar, so that the whole context is preserved. Why would any responsible Identity provider want to give a past identity to a new person, and why would we want to encourage this misbehavior by supporting it ? I think there is a big difference between giving someone an *identity* and giving them an *identifier.* I know that LiveJournal recycles names, and so do other large sites. I think it's more a matter of whether we acknowledge that this is going to happen and try to come up with something that will work for users and site operators or pretend that it's not going to happen and deal with the consequences. That said, I'm mostly trying to collect the whole community's viewpoints into one document to aid in the decision process rather than pushing a particular agenda. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Do We Agree on the Problem We're Trying to Solve?
On 6/8/07, David Fuelling [EMAIL PROTECTED] wrote: If in 50 years, a given canonical URL domain goes away, then couldn't a given OpenId URL owner simply specify a new Canonical URL in his XRDS doc? If I understand the way that David Recordon and Drummond are proposing that canonical identifiers work, this is not the case. The canonical identifier is the sole database key, and the URL that the user enters and everyone sees is reassignable and (to a certain extent) ephemeral. Control of the canonical identifier is necessary and sufficient to assert one's identity. If I understand Dick, he's proposing using multiple identifiers as a kind of multi-factor authentication, where the user has to present more than one credential in the form of identifiers to take an action. This is very similar to your interpretation of two URLs being necessary. It's an interesting idea, and it has a lot of nice properties, but it seems like a pretty big leap at this point. I think the biggest drawback is that the nice properties only really appear when each identifier is issued by a separate authority. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The CanonicalID Approach
On 6/9/07, Martin Atkins [EMAIL PROTECTED] wrote: I'm assuming that the RP authenticates http://inconvenient.example.com/001, not http://impersonation.example.com/mart. Just as with delegation, if I can successfully authenticate as the persistent identifier and the non-persistent identifier points at the persistent one, we can assume that http://impersonation.example.com/mart is me as well. If you agree that: 1. In order to authenticate as the persistent identifier, discovery must be done on the persistent identifier 2. In order to determine that the non-persistent identifier points at the persistent one, discovery must be done on the non-persistent identifier. then two discovery steps are necessary in order to use this scheme. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Questions about IIW Identifier Recycling Table
On 6/8/07, Recordon, David [EMAIL PROTECTED] wrote: The difference I see is that the current secrets can be renegotiated. If we're working with non-public fragments then they cannot be. If we're working with public fragments, then I'm less concerned. I understand your concern, but I don't share it. There will be times that secrets are lost, but I think that the benefit of protecting users from identifier loss is more important than the cost of requiring a reliable provider. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Questions about IIW Identifier Recycling Table
On 6/7/07, David Fuelling [EMAIL PROTECTED] wrote: I'm not sure I understand what's public about this. If I understand it correctly, from the relying party's perspective, the user's account is keyed off of the pair of the identifier and the token. This sounds like URL + private token in that table. Am I missing something? Maybe I don't understand the difference between private and public tokens. My proposal used private information to create a public token that can be sent via AX (thus the hybrid term). Am I understanding the difference between private/public tokens incorrectly? I think I see how we're using the term differently. The token only protects your identifier if the relying party does not ever display it. If the relying party did display it, anyone who gained control of your identifier in the future could just send that (reusable) token along with an assertion in order to gain access to a relying party. Since the relying party needs to keep the token secret, I was calling it private. It's shared between the provider, the user, and the relying party, but it's secret from anyone else. I think it's also important to note that the transport mechanism for the token (using attribute exchange, as an extra field or as a fragment) is independent from whether the token should be shared. I think using attribute exchange for this core feature is a non-starter, since it would create a dependency on the attribute exchange in the authentication spec. This approach was rejected at IIW because: 1. An extra database field is required (whether or not the data is transmitted using attribute exchange) If the AX database schema is architected properly, then the addition of a new AX attribute should not necessitate a new database column. If this were the case, then AX would not really be feasible (how would an RP deal with a new AX attribute?). If you have an existing application and you are adding OpenID support, in order to support the token, you would have to alter your schema. When creating a new application, it's not a big deal. I also expect that few relying parties will support *arbitrary* attributes, since the relying party will not be asking for attributes that do not have specialized uses anyway. Perhaps this deserves clarification on the wiki page. 2. There is no obvious way to tell if a user is the same user across sites (The identifier contains a secret portion) Good point. Although, let's assume that RP's display fragment-enabled OpenID's in the following manner, which overcomes the Fragments are Ugly problem: a href= http://me.example.com#1234;http://me.example.com/a Users will not be able to easily distinguish that the OpenID is owned by a different user without hovering over the URL in their browser. That said, computers will be able to, since the actual HREF is what counts, I assume. Has this been discussed wrt to fragments. There has been some discussion about it. It's a tough issue, and it's one of the reasons that I asked the (surprisingly controversial) question about whether we can just add the token to some part of the URL, if it's going to be publicly available anyway. If it's a visible part of the URL, both users and software agents will be able to tell the difference between identifiers. In the discussions that we have had about this issue so far, we have concentrated on a user gaining access (either on purpose or accidentally) to resources that were controlled by the previous owner of their identifier. For example, a user could sign in to a photo sharing site and see someone else's photos. A related issue is that of a third party mistaking resources controlled by the previous owner of a URL as being controlled by the current owner. For example, a potential employer does a search for the user's identifier and finds photos of some illegal activity, without the uniquifying token as a visible part of the URL. 3. Concern about depending on a secret for a user to be able to sign in to a site (David's Wordpress issue) I think DR had a problem with anything that could be lost, thereby preventing access to an RP. Both Fragments and Tokens seem to suffer from this problem, since in the Fragment scheme, if I or my OP forgets what my fragment was, I won't be able to login to an RP without recycling my account (or forcing an account recovery procedure). Seems like the odds of my OP losing my fragment information are pretty slim. Identically, the odds of my OP losing my recycling_password are pretty slim, too. What's more, If *I* lose my recycling password, why should I care? Only the OP needs to deal with it, and perhaps the OP can just show me that password in an account settings page when I login(?) If the token is publically viewable, then losing it is not an issue. I do not share David's concern about depending on a secret, since both the relying party and the provider already need to store secrets. I think
Re: Questions about IIW Identifier Recycling Table
On 6/7/07, David Fuelling [EMAIL PROTECTED] wrote: Over the last few days I've been thinking about your Identifier Recycling proposal[2], in addition to other proposals (Tokens, etc). Assuming I understand things correctly, it seems as if a hybrid of the public/private token approach would seem to garner the most checks, per the IIW grid. Not sure if my idea is technically correct or not, so please let me know if what I'm proposing falls short anywhere. Here goes I'm not sure I understand what's public about this. If I understand it correctly, from the relying party's perspective, the user's account is keyed off of the pair of the identifier and the token. This sounds like URL + private token in that table. Am I missing something? This approach was rejected at IIW because: 1. An extra database field is required (whether or not the data is transmitted using attribute exchange) 2. There is no obvious way to tell if a user is the same user across sites (The identifier contains a secret portion) 3. Concern about depending on a secret for a user to be able to sign in to a site (David's Wordpress issue) I'm not sure which of these issues were the basis for rejecting this approach. To me, the biggest problem with it is (2) Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Auth 2.0 Extensions: Namespace Prefixes
On 6/5/07, Recordon, David [EMAIL PROTECTED] wrote:
Since it seems no one has replied yet, I'd agree that this would make
implementations easier. Iterating via a regular expression seems ugly
and hard to do (well except in Perl). :-\
-1. It's one more thing to get wrong. There would then be the case
where an extension had a namespace alias declaration but was missing
from that list, or was in that list but did not have a namespace alias
declaration.
Iterating one time to build a lookup table is easy, and you get the
namespace URIs out of that one iteration. It doesn't take regular
expressions (it's just a prefix match), and I've never used a language
that would make this kind of iteration difficult.
Each technique implemented in Python for comparison:
prefix = openid.ns.
prefix_len = len(prefix)
def extractNamespaceAliases(query):
Extract the namespace URIs from a dictionary containing a
parsed HTTP query string or POST body. Returns a dictionary from
namespace alias to namespace URI.
This code implements the current draft of the OpenID 2.0
specification. Very straightforward.
namespace_aliases = {}
for k, v in query.iteritems():
if k.startswith(prefix):
alias = key[prefix_len:]
namespace_aliases[alias] = v
return namespace_aliases
def extractNamespaceAliases1(query):
Extract the namespace URIs from a dictionary containing a
parsed HTTP query string or POST body. Returns a dictionary from
namespace alias to namespace URI.
This version implements the proposal in this thread. The code has
more branches and has to build new strings as lookup keys.
namespace_aliases = {}
namespace_string = query.get('openid.extensions')
# Ignore missing or empty openid.extensions parameter
if namespace_string:
aliases = namespace_string.split(',')
for alias in aliases:
try:
namespace_aliases[alias] = query[prefix + alias]
except KeyError:
pass # Ignore declared but missing extensions
return namespace_aliases
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Re: The WordPress User Problem (WAS: RE: Specifying identifier recycling)
On 6/5/07, Recordon, David [EMAIL PROTECTED] wrote: Imagine if I install WordPress (or insert other app here) on https://davidrecordon.com and check the Use fragments to protect my OpenID box. A few months later I decide to remove WordPress, or an upgrade blows away my OpenID extension data, or I'm using an extension which stores the fragments in /tmp/ and they get blown away. I now no longer have access to my accounts on all the relying parties I've visited. Now what do I do? The fragment is not secret. It is not protecting your OpenID. You should be able to get the fragment from any relying party that you visited. You might choose to use a fragment if you have acquired a recycled identifier, but you can choose the fragment. It protects *nothing* if you control the base identifier (to the point that you can choose an OpenID provider). I'm not arguing for or against a particular approach here, but I think your argument is flawed. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The WordPress User Problem (WAS: RE: Specifying identifierrecycling)
On 6/5/07, Drummond Reed [EMAIL PROTECTED] wrote: I supposed this doesn't apply to large sites, where all identifiers are managed in trust for users and they can enforce non-access to previous fragments. But for personal URLs it doesn't appear to work at all. Am I missing anything? Enabling recycling for large sites that control their own identifiers was the use case that was declared mandatory to cover for the OpenID 2.0 specification. I would personally like to have a solution that protects identifiers without a central manager, but that is not the case that is holding up OpenID 2.0. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Specifying identifier recycling
Hello, I started writing up the use of fragment identifiers for URL-recycling for the OpenID 2.0 authentication spec, and I ran into some unforseen challenges. It's not obvious how a relying party should behave when a URL with a fragment is entered. How should the discovery process work? How should fragments work with delegation (both as the claimed identifier and the provider-local identifier)? After thinking this over for a while, I'm no longer convinced that using URI fragments as the uniquifying value is the right approach. Looking at the available options, I think that the best approach might be to add a uniquifying value to some part of the URL, in a provider-specific manner. For instance: I own http://josh.myopenid.com/. I delete my account, and so it goes back in the pool of identifers. The next Josh who registers the username josh at MyOpenID.com gets http://josh.myopenid.com/1. Providers can also provide a redirect from the general form of the identifier to the current version of the identifier so that users do not need to remember or type the uniquified version. This is pretty much equivalent to the fragment scheme, except: * It does not require spec changes (and is backwards-compatible!) * The uniquifying component is user-visible I'd like to hear opinions on whether this unique-URL solution is good enough to solve the problem. If you think it isn't, I'd like suggestions on how discovery and delegation should interact with fragments. Josh For reference, here's a comparison of the three different approaches to solving the identifier recycling problem: 1. Using a URI fragment with a uniquifying value: * No database changes necessary on the RP (the RP can store the URL with the fragment as the identifier) * Potential problems with initiation and discovery * Potential problems with inconsistent behaviours on OpenID 1 sites * Comparing identifiers is easy * URLs that user see may be ugly or inconsistent across sites (if some relying parties do and others do not strip the fragment before display) * There is no difference between different versions of a *user-displayed* identifier (users can't tell if a reference to a URL in the wild belongs to the current ownder of a URL or another user). 2. Adding an extra field with a uniquifying value: * Database change required * No change in initiation or discovery * OpenID 1 sites will behave as they do now * Identifier comparison is no longer obvious * Display URLs are easy * There is no difference between different versions of an identifier 3. Just use different URLs: * No database change required * No change in initiation or discovery * No implementation change at all (just a new best practice) * Comparing identifiers is easy * Display URLs are easy * Users can tell the difference between an old and a new identifier ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Realm spoofing spec patch
Allen, On 5/29/07, Allen Tom [EMAIL PROTECTED] wrote: From an implementation perspective, it might make sense for the OP to verify the RP during the association request, so that the association handle is only returned after the RP has been verified. Were you concerned about implementation complexity or the time it could take to do discovery while the user is waiting? At association time, the provider does not know who the relying party is. Are you proposing that the realm be included in the association request? In that case we'd have to include the discovery URL, in the case of a wildcard realm. I see two potential problems: 1. If the discovery happens during the association request, a single-threaded relying party might not respond to the verification request. This wouldn't come up too frequently in production, but it would raise the bar for example and prototype code. 2. If the form of a return_to URL changes (and the relying party updates the discovery information to match) it would be good if the provider could attempt verification again, so that a valid request could complete successfully. (2) requires the same flow as the proposed implementation (verification during the course of the request), and so I think it's simpler to just leave it in-band. I suppose that the specification could remain silent on *when* to perform the verification, since it doesn't really matter from a security perspective, which would leave both channels open, as long as the pertinent information was added to the association request. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: clarifying section 11.2 in draft 11 for HTML discovery?
On 5/24/07, Peter Watkins [EMAIL PROTECTED] wrote: Shouldn't the spec clarify what is required for an HTML discovery to uphold an assertion that triggers 11.2's discovery process? The spec as it is currently written does not support using identifier selection with HTML discovery. That was intentional, to keep things simpler. A user should never have to add markup to trigger identifier selection. That is the responsibility of the OpenID provider. I don't think we need to add a way to trigger identifier selection with HTML discovery. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Realm spoofing spec patch
Hello, I've added a section to the specification[1] about performing verification on the realm to avoid realm spoofing. In short, realm spoofing is the problem of exploiting a bug on a site that a user would trust to trick them into sending their information to a site that they would not trust. This is very similar to many phishing attacks. The difference between this type of attack and a standard phishing attack is that the user will (usually) only see the realm, and the realm may actually be trusted, so even an educated user who's paying attention may be vulnerable. There are also (minor) changes to the section on discovering relying parties[2]. The fix that is described is for the relying party to provide a whitelist of URL patterns that should be usable as return_to URLs. Relying parties should be as restrictive as possible when specifying return_to URLs. This is the fix that was discussed at the Internet Identity Workshop, by all of the spec editors and several prominent members of the OpenID community. Please review the additions. If you'd like to see the specific changes, you can look at the diffs in revision control[3]. Josh 1. http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn-327.html#return_to_verification 2. http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn-327.html#return_to_verification 3. http://openid.net/svn/listing.php?repname=specificationspath=rev=326sc=1 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 5/18/07, Marius Scurtescu [EMAIL PROTECTED] wrote: On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote: In order to be backwards compatible the HTML page should have two sets of tags one for OpenID 1.1 and one for OpenID 2.0, both pointing to the same OP endpoint URL. Otherwise an OpenID 1.1 RP will not be able to use the HTML page. Also note that it's allowed to put both values in the rel attribute of one tag [1], which eliminates a little bit of bloat. Josh 1. http://www.w3.org/TR/html401/struct/links.html#adef-rel ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 5/18/07, Dmitry Shechtman [EMAIL PROTECTED] wrote: I'm sure that this will break a few implementations It certainly will break PHP-OpenID. Which implementation are you referring to as PHP-OpenID? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification
Don, On 5/18/07, Don MacAskill [EMAIL PROTECTED] wrote: My company, SmugMug, is an OpenID provider for hundreds of thousands of high value paying accounts, and will shortly be a consumer as well. I'll freely admit that I haven't fully digested 2.0's pre-spec, but at least part of that reason is it looks like it adds a lot more complexity. I can honestly say that if I had seen it as a spec, rather than 1.1, I would have certainly put off implementation, possibly indefinitely. As I have said a few times, the OpenID 2.0 specification is significantly longer than the OpenID 1.1 specification, but most of the length comes from being explicit and rigorous about things that the OpenID 1.1 specification is not. I welcome specific suggestions for simplifying or otherwise improving the specification. The more feedback that we get, the better. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification
On 5/17/07, Sam Alexander [EMAIL PROTECTED] wrote: 1. Identifier recycling. There are two different use cases for identifier recycling. The first, and the one that most people who I have talked to really want to solve is that of a large provider that wants to allow re-use of parts of its namespace. The second is if a user wants to relinquish control of an identifier without relinquishing control of the places that they have used this identifier. A concrete example of this is if I ever choose to stop paying for j3h.us. This problem has already existed in the realm of e-mail for years (which I think is a great precedent for the problems we will (and do) face with OpenID). OpenID does an even better job of mitigating it because of built-in delegation. I think this should be left up to the OP to iron out (at least for now), and shouldn't be considered a block for finalizing the OpenID 2.0. There is a proposed solution that we had consensus on (Dick's fragment proposal.) This issue is a road block for certain companies who have a large existing user base. I think that if we can solve it without too much complexity and without taking too much time, we should. 2. Realm spoofing. This encompasses the attacks that Allen Tom has described (using redirectors, proxies or XSS attacks) that create new phishing opportunities and make certain types of phishing even worse. There are solutions popping up like Verisign's plugin and our myVidoop implementation that are taking shots at how to battle phishing. This is a totally different kind of phishing/proxy attack. This is not an attack against the provider. Whether an authentication technology is phishable is irrelevant to realm spoofing. Essentially, realm spoofing uses holes in *relying party* sites to make users send data to attackers. Read Allen Tom's messages that describe the problem for more specific information about it. As with the recycling issue, there are a couple of relatively simple suggestions that make this problem a lot less severe. It's also a pre-requisite for getting larger companies to adopt OpenID, so I think it's worth addressing. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 5/17/07, Alaric Dailey [EMAIL PROTECTED] wrote: There are 2 issues that I would like to see addressed. 1. Forcing Encryption, to protect users data en-route. 2. Validated assertions, validating certain bits of data with a third party. I know both of these have come up before, but have met with resistence, I would submit that with Sun and AOL supporting OpenID that these issues become more important, especially protecting the users data. There are valid use cases for both of these features, but I think that they can be addressed in a future release of OpenID. I want to get the features that are already implemented out to users. Part of what will be nice about getting 2.0 out is that it will give us more freedom to start playing with new ideas. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 5/17/07, Alaric Dailey [EMAIL PROTECTED] wrote: I hate to be a PITA but these issues were brought up a while ago by Eddy Nigg and Myself. I understand, but at that time, as now, I was trying to get the spec to be finished. We've been in something of an informal feature-freeze for a while. Perhaps we should have explicit feature-freezes. I'd suggest starting an OpenID 3 thread to talk about the features that you want to add. That way, you can start trying to convince people that your features should go in without having to battle with people like me who just want to have a stable spec release with the improvements that we already have. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: encoding newlines in attribute values
On 4/19/07, Marius Scurtescu [EMAIL PROTECTED] wrote: I think we do need pre-URL-encoding, mainly because of signatures. In order to calculate the signature the parameters must be put together in a special way and new line characters are not allowed. Yes. The key-value encoding that's used for POST responses (to associate and check_authentication) is also used in signature generation. This is the source of the restriction on newlines in values, not anything to do with URL encoding. Each attribute already has to define its encoding rules and data-type. The mechanism for encoding a newline can be part of this encoding, if newlines are allowed in the value. Once there is one attribute that has a defined encoding for newline, when new attributes are defined, they can re-use this encoding. Does that sound reasonable? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Label replacing Key
On 4/7/07, Douglas Otis [EMAIL PROTECTED] wrote: This would then require all locations that use the term key when referring to a field label to be changed to label -1 If it needs to be changed, Martin's suggestion of name instead is much better. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)
On 4/6/07, Dick Hardt [EMAIL PROTECTED] wrote: On 5-Apr-07, at 9:18 AM, Recordon, David wrote: I'm fine with doing things differently, I'm not arguing that a metadata format should not be created, just that IMHO for simplicity sake of reading the AX documents this format description should be merged into the core protocol spec. If down the road it should be split out then it always can be. Well, as one of the people that wrote the documents. We decided that having separate documents was better. Thanks for sharing your opinion. I have a different opinion. Having started an implementation, I'm glad that metadata is not part of the core, because metadata is not necessary for a wide range of applications. I think it will be useful eventually, but I'm glad that I can implement the core completely without thinking about metadata. If metadata were part of the core (even optionally!) I might not have even started writing code. I do wish that this thread did not contain so much bickering. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Logout
On 4/6/07, Praveen Alavilli [EMAIL PROTECTED] wrote: well with OpenID atleast, I think we can easily design a logout extension, [...] Any reason why something like this was not incorporated into the specs yet ? There is not general agreement on how this feature should be implemented, or even exactly how it should work. Anyone care to search back through the list archives and dig up the many previous discussions of this topic? It'd be useful to the discussion to gather the previous discussions together and make a wiki page about sign-out with links to the previous discussions and a summary of the issues and possible solutions to those issues (rather than a proposal). Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attribute Exchange 1.0 svn revision 295 review
On 4/6/07, Dick Hardt [EMAIL PROTECTED] wrote: I agreed with you previously that the response being able to work either way if the request can. Sorry if that was not clear. Great. That will simplify the code. Given this change, is there still the need to have the special case for sending an empty string as a null value? That case can be covered (explicitly) by using count=0, even if omitting a requested value is still illegal (see below). Another restriction on the response message is that you have to send responses even if they are empty. Can you give the rationale for requiring the fields with no values to be sent? I am unclear on what your question is. Would you clarify? Section 5.2 states: A response parameter MUST be sent for each requested attribute alias. This enables the RP to know that the OP did process the request. Does it that the relying party will know that each requested attribute was processed, or the request as a whole? And what would the relying party be able to do if it got a response that indicated that the OP had not processed the request? (send a bug report?) Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Logout
On 4/6/07, Praveen Alavilli [EMAIL PROTECTED] wrote: I could only go only till Aug 2006 on the mail archives here: http://openid.net/pipermail/specs/ and nothing found specifically on logout' (atleast based on the thread subjects). I'd also search the other mailing lists, because the discussions on each of them tend to blur together (spec issues on general, and so on). I'll have to remember to bring the search issue up the next time someone suggests Yet Another Mailing List. Any one know how and where we could get older archives ? http://lists.danga.com/pipermail/yadis/ Can we get a copy of these archives on openid.net? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attribute Exchange 1.0 svn revision 295 review
On Apr 5, 2007 at 8:41 AM, Dick Hardt [EMAIL PROTECTED] wrote: There is no way to say I want as many of X as you have, and I don't care how many that is Good point. Perhaps have a magic value like -1 to indicate as many as the user will release? I had thought the RP would likely have a maximum they would want in most situations. Generally, yes, although when we were discussing the spec, we talked about using one pass of attribute exchange to get all of the available attributes and another pass to request the attributes themselves. When requesting the available attributes, it seems like you'd want to say give me all the attributes that are available instead of give me up to 500 available attributes, but I could be wrong. It might be good to give a bound on the response size for every request, although in cases such as above, it might be useful to the relying party to know if there were values that overflowed the limit. It wouldn't be difficult to add a flag, but I'm also not sure whether it would be worth the extra complexity. There is the issue that I brought up in a separate message where count=1 is different from not specifying a count, even though they both mean 1 or 0 values. The perl way would be to have more then one way to do it and allow both methods to mean the same thing. The python way would be there is one way to do it and not allow count=1 in a request Well, clearly it's better to have one way to do it. But seriously, the main problem that I have with it is that the specification prescribes the response format based on the request format. That is, my code has to keep track of whether the request used count=1 or just didn't specify a count, instead of just recording that the request asked for one value, so that the later code can know how to encode the value. If there's really more than one way to do it, you should be allowed to do it either way. I'm guessing that you made that restriction on the response format so that relying parties can know what the form of the response will be. Is that correct? Another restriction on the response message is that you have to send responses even if they are empty. Can you give the rationale for requiring the fields with no values to be sent? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attribute Exchange pre-draft 5
On 3/26/07, Johnny Bufu [EMAIL PROTECTED] wrote: Since draft_4 [1] we've done some implementation and testing (as well as listened to community's suggestions on related issues), and have incorporated some changes into a pre-draft-5. Before publishing it I would like to see your comments about them or about other features / changes that would be useful in AX. If I understand correctly, the response to a request for an attribute with count.x=1 is different from the response for a request with no count specified, even though the meaning is the same. (namespacing left off for clarity) Request: .type.a=http://example.com/a .count.a=1 .type.b=http://example.com/b Response: .type.a=http://example.com/a .count.a=1 .value.a.1=avalue .type.b=http://example.com/b .value.b=bvalue Even though the request for a and b have equivalent meaning (send zero or one values for this attribute) the response MUST encode them in different ways. I think this is ugly, because the detail of the way that the attribute was requested has to be preserved in the code, to ensure that the response can be encoded correctly. (it's not sufficient to just default the count to one if it's not specified) Is there a reason that it's specified this way? I'd prefer if there was only one way to do it. Also, can the count be zero in the response? it seems like that's OK, and if it is, it'd address my concern about overloading zero-length strings to mean no value. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
SREG namespace URI rollback
I'd like to change the simple registration specification so that it uses the type URI that is currently in use in at least PIP and MyOpenID as the namespace URI instead of defining a new value. As far as I can tell, the only difference between the 1.0 and 1.1 simple registration specifications is adding the namespace URI. The names and meanings of all of the fields are the same, so there is no compatibility issue, and the URI for 1.0 is already reserved (because it's used as the Type URI in XRDS documents). In short, I don't think that the SREG namespace/type URI should change until there are incompatible changes to the simple registration specification. So are there any objections to rolling the URI back to http://openid.net/sreg/1.0 from http://openid.net/extensions/sreg/1.1? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: SREG namespace URI rollback
On 4/2/07, Johnny Bufu [EMAIL PROTECTED] wrote: I think the missing namespace in SREG1.0 can cause problems; take this example: I was not proposing that we drop the namespace. Just that we don't introduce a new URI when the protocol is otherwise identical, and instead just use the existing type URI as a namespace URI. That is, an SREG 1.1 request looks like: openid.ns.s=http://openid.net/sreg/1.0openid.s.nickname=j3h not: openid.sreg.nickname=j3h If you use sreg as the namespace alias, SREG 1.1 is identical to SREG 1.0. Is that clearer? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attribute Exchange pre-draft 5
On 4/2/07, Rowan Kerr [EMAIL PROTECTED] wrote: On 2-Apr-07, at 3:16 PM, Josh Hoyt wrote: What about attributes whose value could reasonably be an empty string? It would be reasonable to answer don't do that, I'm just curious how you expect this case to be handled. I'd say it's up to the RP to decide whether the data returned is valid for it's specific needs. I'm thinking about differentiating between an attribute that's not available and an attribute that *is* available, but its value is . I. e. difference between a null pointer, and a pointer to an empty string. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: SREG namespace URI rollback
On 4/2/07, Recordon, David [EMAIL PROTECTED] wrote: Sure, though I think there has also been a desire to do a bit of an actual rev to SREG to be more of a 1.1 version in terms of either explicitly supporting additional fields (such as avatar) or allowing field names to be URIs themselves versus a hard-coded list of properties. -1 SREG works because it's so dead simple. Attribute exchange is not much more complicated, and it lets you specifiy field names with URIs *and* allows you to define any attributes you see fit. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: modulus and generator optional in association requests
On 3/20/07, Granqvist, Hans [EMAIL PROTECTED] wrote: Once something complex is optional, typically few will implement it, which means you can run into the inverse: implementations that do supply optional values run into parties that cannot treat those values correctly. They are optional in OpenID 1, so the cat's already out of the bag. I see no reason to make them required in OpenID 2, since this case will already need to be implemented. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OA2.0d11: Minor nit-pick regarding normalization
On 2/1/07, Martin Atkins [EMAIL PROTECTED] wrote: The normalization table in appendix A.1 lists several examples of the normalization of URIs. The last few examples are as follows: http://example4.com/ = http://example4.com/ https://example5.com/ = https://example5.com/ example6.com = http://example6.com I believe that the last example should instead normalize to: http://example6.com/ You're right that the example needs to have the slash added. I don't think that we need any extra wording because RFC3986, which we reference for the normalization rules says: a URI that uses the generic syntax for authority with an empty path should be normalized to a path of /. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
On 2/2/07, john kemp [EMAIL PROTECTED] wrote: Don't get me wrong - I think it's a good idea for the OP to make a statement about the authentication method used (although I would prefer it to say something like authn_method=urn:openid:2.0:aqe:method:password, rather than phishable=yes). That points to AQE, as David mentioned already. A browser plug-in, like sxipper, that uses a username and (a generated, non-user-visible) password internally and will only submit it to the correct OP can't be phished. Is this a different kind of authentication than password? I don't think so. Is it phishable? I think that the OP can reasonably say that it is not. Therefore, I think that the authentication mechanism is (or at least can be) independent from whether the authentication channel is phishable. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Proposal: An anti-phishing compromise
Hello, I've written up a proposal for an addition to the OpenID Authentication 2.0 specification that addresses the phishing problem. I've had some off-list discussion of it, and I think it may strike the right balance. Please provide feedback. Josh Background == We have had a lot of good discussion about how phishing relates to OpenID. There seems to be consensus that the OpenID Authentication spec should address these issues, but not consensus on how that should happen. The ways that OpenID can potentially make phishing worse: * Redirects to your provider are a fundamental part of the flow of OpenID, so being redirected to a phishing site is easy to miss * Every relying party (necessarily) needs to know who the provider is in order to verify the authentication response. This means that the site knows what UI it needs to use to phish (and even worse, it can just proxy the user to the provider) I think these two issues cover what makes phishing potentially a greater threat when using OpenID. Although these problems are significant, if a user can authenticate to their OpenID provider through an non-phishable mechanism, OpenID can make the phishing problem *less* of a threat, because there are fewer places that will need to ask for credentials. Other relevant issues: * There is no universally deployed solution to the phishing problem * There is not even a universally *accepted* solution to the phishing problem * Any technology that prevents phishing will require user-agent support or else will fundamentally change the flow of OpenID (prevent relying-party-initiated sign-in) * OpenID is intended to be deployed without requiring specific technologies to be present in the user-agent * Any general anti-phishing technology can be applied to OpenID Proposed Change === Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. Analysis This proposal is a simplification of the Assertion Quality Extension [1] (AQE), and is essentially the same as what Ben Laurie proposed earlier [2]. It does not attempt to replace the AQE or require it for authentication in general. Benefits The proposal is trivial implement, it acknowledges that phishing is a problem, and forces implementers think about it. If more assurances are required, then the AQE, whitelists, and other mechanisms still need to be employed. This field just sets a minimum bar. I think that this is the right information to require, because it addresses this one thing that makes OpenID potentially worse for security, but it does not mandate specific technologies. It pushes the liability for phishing relying parties to OpenID providers, who are the ones who should be responsible for taking measures to prevent phishing. IANAL, so I don't know if this has any real teeth, but it does make it clear to people who are implementing OpenID providers that it is intended to be their responsibility to deal with the phishing issues. Drawbacks - It may be tricky to define what is meant by non-phishable. There is no way for a Relying Party to *ensure* that the OpenID provider indeed uses non-phishable authentication. If libraries are used, the library user may not read the relevant parts of the specification about phishing, and so may remain ignorant of the phishing issues. Why this should be in the core spec --- I believe that this one piece of information would be required more often than not, given the phishing implications. The prominence of being in the core specification makes it harder to ignore the phishing problem. References == 1. http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html 2. http://openid.net/pipermail/general/2007-January/001340.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: DRAFT 11 - FINAL?
On 1/30/07, Recordon, David [EMAIL PROTECTED] wrote: Yeah, I'm not a big fan of openid2.* though it was the simplest method of fixing up HTML discovery to work with multiple protocol versions. I know Josh thought about this more than I did though. 1. Before authentication is initiated, the RP needs to determine what the protocol is. This could be done via discovery on the OP, but there has been general rejection of adding yet another discovery step. 2. A user may have one service that provides OpenID 1 and another that provides OpenID 2. If this is the case, then the version information needs to be bound to the link tag that contains the information. Given (1), the information needs to be embedded in the HTML markup. Given (2), the information needs to be tied to the specific link tag. For example: link rel=openid.server href=http://op.example.com/openid1; link rel=openid2.provider href=http://op.example.com/openid2; vs. link rel=openid.server href=http://op.example.com/openid1; link rel=openid.provider href=http://op.example.com/openid2; link rel=openid.protocol_version href=http://specs.openid.net/auth/2.0; While it is true that since the link relationship names changed, the openid2 is technically redundant, I think it is much clearer to everybody what is going on if the link relationship contains the version number. If the protocol version were to keep changing, I'd argue for a different solution. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: HTML parsing in HTML-based discovery
On 1/26/07, Martin Atkins [EMAIL PROTECTED] wrote: And, in theory, the OpenID spec could add additional restrictions to fix the above problems. Whether it should or not is of course up for debate; I'd be interested to hear from Brad Fitzpatrick and JanRain's developers who are responsible for the most-used implementations currently using regex parsing. Why didn't you guys use an HTML parser? I assume there must have been a reason. While our parser [1] is implemented using regular expressions, I don't think it's what most people mean when they say parsing with regexps. The reason that (most of) the JanRain libraries don't use an HTML parser is because I was afraid that loose parsing of HTML could lead to OpenID discovery markup being recognized in parts of the document other than the head, leading to vulnerabilities where someone could hijack a URL by e.g. adding a malicious comment to a blog. When implementing this parser, I tried to be aware of both the varied markup that exists across the Web and the security implications of different parsing strategies. In short, the parser tries to recognize any OpenID markup that is unambiguously in the head of an HTML document and reject anything else. If you're interested in the details, read the comments at the top of the file (again, [1]) The parser does not work for some valid XHTML cases, most notably using an explicit XML namespace for the XHTML tags. It also does not deal with some cases of valid HTML 4. [2] I am sure that there are other cases in which valid markup is not recognized. My implementation and design strategy was to implement something that is immune to the attacks that I could conceive and work for the vast majority of the cases that exist in the wild. Ironically, another reason that we implemented this parser instead of using an (X)HTML parsing library is that according to the spec, only certain entities should be processed in the link tag's attributes, and a real (X)HTML parser would process all of the entities. It's arguable whether processing the entities is right or wrong, because the user who marked up the page is violating the spec, but I figured that by following the spec exactly, the users who put in this markup would have a more consistent experience (i.e. their markup would be broken for all libraries rather than accepted by some and rejected by others) In an ideal world, we'd be able to specify that the document was e.g. valid XHTML and just use a nice, strict parser on it. The reality of the situation forces us to deal with the markup that's out there, which leads to trade-offs, no matter how we choose to deal with that markup. Josh 1. http://www.openidenabled.com/resources/darcsweb?r=python-openid;a=headblob;f=/openid/consumer/parse.py 2. http://www.intertwingly.net/blog/2006/12/28/Unobtrusive-OpenID#c1167404328 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11
On 1/22/07, Ben Laurie [EMAIL PROTECTED] wrote: On 1/22/07, Ben Laurie [EMAIL PROTECTED] wrote: OK, the idea is pretty simple. Rather like the OpenID Authentication Security Profiles you have a profile where the RP states what kind of End User/OP authentication is acceptable to it. Sites with low/zero value attached to the login can accept any kind of EU/OP auth, whereas high value sites can require unphishable auth. I like the sound of this proposal, but I don't see how the RP could know whether the OP is actually using unphishable authentication when that kind of authentication is requested. Is it necessary for the RP to be able to tell for sure, and if so, how could it tell? No, I don't think it is necessary. If users want to trust their identity to OPs that lie, that's their decision. In that case, I think this could just be part of the Assertion Quality Extension. [1] I haven't been involved in that specification at all, but my understanding is that it provides a way of expressing what kind of authentication the RP would like to have when a request is made to the OP. Josh 1. http://openid.net/specs/openid-assertion-quality-extension-1_0-01.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: HTML-Based Discovery with OP Identifiers
On 12/28/06, David Recordon [EMAIL PROTECTED] wrote: That is a bit confusing to parse so we were looking at re-wording it. Issue is Claimed Identifier is defined as possibly being a User-Supplied Identifier which in turn can be an OP Identifier thus making this paragraph fall apart. From 7.3.1: If the end user did not enter an OP Identifier, the following information will also be present: * Claimed Identifier * OP-Local Identifier The Claimed Identifier can not be an OP identifier. Therefore, I think there is not a problem with the way that HTML discovery has been specified. I don't have time to write up why right now, but I'm -1 on adding a type field to HTML discovery. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consistency of negative responses to checkid_immediate requests
Reviving an old thread... On 12/14/06, Johnny Bufu [EMAIL PROTECTED] wrote: On 14-Dec-06, at 12:13 AM, Josh Hoyt wrote: On 12/13/06, Martin Atkins [EMAIL PROTECTED] wrote: Josh Hoyt wrote: It's confusing to me make the failure response to an immediate mode request be id_res, especially if that is not the failure response for setup mode. I can't see a reason that they can't both use the cancel response to indicate that the OP or end user do not wish to complete the transaction. This is a very minor change, but it will make the spec simpler. I think the RP will want to do something different in these two cases. That's true, but the RP will probably need to handle the success case differently for immediate mode anyway (e.g. it will have to do AJAX to update the page) so I expect it to have a specific return_to URL for immediate requests. Since using a different return_to is trivial, I prefer the consistency of negative responses. The current / v1 modes will need to be mentioned in the compatibility section, and also implemented. Not sure if this simplification will then still be worth. Since the user_setup_url parameter is now gone, there is no way to differentiate between a broken/truncated response and a cancel response to an immediate mode request. I think that there needs to be *some* positive way to identify cancellation of immediate mode requests, rather than depending on lack of other parameters. I'd be happy with any of these ways to positively identify a cancel response to checkid_immediate: 1. re-using cancel as I suggested above 2. introducing a new mode (e.g. setup_needed ) 3. adding a parameter that the id_res response is an immediate cancellation (e.g. openid.setup_needed=true) I no longer buy the argument about having to support the OpenID 1 mechanism in the library, since cancellation of an immediate mode response is already indicated differently between OpenID 1 and 2, so it's really just a matter of what goes into the OpenID 2 code path rather than whether the two code paths exist. Pseudo-code for the current approach: def isSetupNeeded(): if this is OpenID 1: return whether there is a user_setup_url parameter if this is OpenID 2: # This is the branch that I want to change return whether there are any other OpenID parameters passed at all Thoughts? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: Section 4.1.1 - Key-Value Form Encoding If in the key-value form, I wish to transmit a value that includes a '\n', what am I supposed to do? Encode it such that it doesn't have a '\n' in it, e.g using base64. If '\n' was allowed, the protocol would permit the kind of attack described in this thread: http://openid.net/pipermail/specs/2006-November/000901.html I understand that is one possible fix. What about we define one of the possible fixes as the canonical fix for text data, otherwise different implementors will implement different fixes (base64, C- style \n, URL-style %0D%0a, ... ) and interop will suffer. I'm uncomfortable defining an escaping mechanism when there are different possibilities that are appropriate for different contexts. I think that extension authors will define an appropriate scheme for the problem that they are solving (e.g. if it's binary data, use base64), and everyone who is using that extension will use that same encoding, so there will not be interoperability issues. If there were multiple extensions defining escaping mechanisms today, and they agreed, then I might agree to specify one, but there are not, so I'd rather leave it open. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: 10 Responding to Authentication Requests First sentence: When an authentication request comes from the User-Agent via indirect communication (Indirect Communication), the OP SHOULD identify the User-Agent, and determine whether the end user wishes to complete the authentication. I have no idea what the term identify means here. Do you mean: When an authentication request comes from the User-Agent via indirect communication (Indirect Communication), the OP SHOULD determine the validity of the current session of the User-Agent with the OP, and -- with or without direct interaction with the user, this is left to implementors -- determine whether the end user wishes to complete the authentication with this particular RP. Re-worded in http://openid.net/svn/listing.php?repname=specificationspath=%2Frev=235sc=1 New text: When an authentication request comes from the User-Agent via indirect communication (Indirect Communication), the OP SHOULD determine that an authorized end user wishes to complete the authentication. If an authorized end user wishes to complete the authentication, the OP SHOULD send a positive assertion (Positive Assertions) to the Relying Party. Methods of identifying authorized end users and obtaining approval to return an OpenID Authentication assertion are beyond the scope of this specification. I think that's all the issues that were in my court. Did I miss anything? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consistency of negative responses to checkid_immediate requests
On 12/13/06, Martin Atkins [EMAIL PROTECTED] wrote: Josh Hoyt wrote: It's confusing to me make the failure response to an immediate mode request be id_res, especially if that is not the failure response for setup mode. I can't see a reason that they can't both use the cancel response to indicate that the OP or end user do not wish to complete the transaction. This is a very minor change, but it will make the spec simpler. I think the RP will want to do something different in these two cases. That's true, but the RP will probably need to handle the success case differently for immediate mode anyway (e.g. it will have to do AJAX to update the page) so I expect it to have a specific return_to URL for immediate requests. Since using a different return_to is trivial, I prefer the consistency of negative responses. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
On 12/14/06, Johannes Ernst [EMAIL PROTECTED] wrote: So you believe that it is tight enough that if you and I implement the spec, and somebody types the exact same character string into both of our implementations, it will produce the exact same result, regardless what the character string was? Yes, that's what I think. :) Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Off-topic: Re: Comments on Auth 2.0 - Pre-Draft 11
On 12/14/06, Joaquin Miller [EMAIL PROTECTED] wrote: I have changed that text from needs to to MUST, although I think that the sentence before that (The end user's input MUST be normalized into an Identifier) is pretty unambiguous. I feel this is an excellent change. This style should be followed throughout. The problem with 'needs to' and 'MUST' in the same document is that it leaves the reader this little puzzle to puzzle over: What is the normative difference between 'needs to' and 'MUST'? Why is 'needs to' used here and 'MUST' there? Is 'needs to' weaker than 'MUST'? Is 'needs to' stronger than 'SHOULD'? I doubt that the needs to wording would have ever caused any problems with implementation. The sentence before states that you MUST normalize the input. The needs to was describing a condition that is necessary to check in order to perform the normalization. Anyone who was attempting to implement the normalization algorithm would see that it is necessary to determine the type of the input before continuing. I think that words like MUST and SHOULD are not necessary when describing how to do something whose importance has already been made clear (by a MUST, etc.). I have a hard time reading prose that uses those words excessively, because if they are over-used, they become noise (you already said I MUST normalize). Anyway, I think the OpenID 2.0 Authentication specification is pretty consistent about using the appropriately strong wording when it's not already clear whether something is required, so I think this discussion is mostly academic. Feel free to make requests if there are specific parts whose compliance is not obvious. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consistency of negative responses to checkid_immediate requests
On 12/14/06, Johnny Bufu [EMAIL PROTECTED] wrote: On 14-Dec-06, at 12:13 AM, Josh Hoyt wrote: On 12/13/06, Martin Atkins [EMAIL PROTECTED] wrote: Josh Hoyt wrote: It's confusing to me make the failure response to an immediate mode request be id_res, especially if that is not the failure response for setup mode. I can't see a reason that they can't both use the cancel response to indicate that the OP or end user do not wish to complete the transaction. This is a very minor change, but it will make the spec simpler. I think the RP will want to do something different in these two cases. That's true, but the RP will probably need to handle the success case differently for immediate mode anyway (e.g. it will have to do AJAX to update the page) so I expect it to have a specific return_to URL for immediate requests. Since using a different return_to is trivial, I prefer the consistency of negative responses. The current / v1 modes will need to be mentioned in the compatibility section, and also implemented. Not sure if this simplification will then still be worth. That's a good point. I guess it comes down to how long OpenID 1.1 support will be necessary. If it's a long time (effectively forever) then it's definitely not worth it. If it's a relatively short period of time, then I think it is worth it for the cleaner spec. Unless someone agrees that it'd be worth it, I'll leave it alone. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: 7.1 Initiation Given recent discussions on logo and User Experience, this needs to be different. Instead of: To initiate OpenID Authentication, the Relying Party SHOULD present the end user with a form that has a field for entering an Identifier. It is RECOMMENDED that a Relying Party place the OpenID logo at the beginning of the form field where the end user enters their Identifier. This aides in end user recognition that they can use an OpenID enabled Identifier at the Relying Party. Better: This document does not define a user experience. It is RECOMMENDED that implementors follow the OpenID user experience if and when such an OpenID user experience has been defined in a separate document. Proposed resolution? I've taken out the logo recommendation and left it with an input field in a form with the appropriate name attribute. The user-experience document won't contradict *that* much, and it's a technical necessity (for e.g. smart software agents to detect the login field). See http://openid.net/svn/listing.php?repname=specificationspath=%2Frev=212sc=1 Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
Oops, forgot to copy the list... On 12/14/06, Josh Hoyt [EMAIL PROTECTED] wrote: On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: 9.1. Request Parameters ... Note: If an OP-SPecific Identifier is not supplied, the Claimed Identifier is considered to have the same as the OP- Specific Identifier. If neither value is present, the assertion is not about an identifier, and will contain other information in its payload, using extensions (Extensions). This doesn't seem right; I read your text like this: If an OP-Specific Identifier is not supplied and therefore openid.identity = http://openid.net/ identifier_select/2.0 the Claimed Identifier is considered to have the same as the OP- Specific Identifier. openid.claimed_id = http://openid.net/identifier_select/2.0; Which is fine, but doesn't cover the remaining cases, i.e. when Claimed Identifiers / OP-Specific Identifiers *are* supplied. The original / current wording does cover these cases, albeit I admit it is not very easy to read. So I modify my request to modify the wording in a way that it is easier to read. Attempted. See http://openid.net/svn/listing.php?repname=specificationspath=%2Frev=201sc=1 and http://openid.net/svn/listing.php?repname=specificationspath=%2Frev=209sc=1 Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
On 12/12/06, Joaquin Miller [EMAIL PROTECTED] wrote: How about one of these: When a message is sent as a POST, OpenID parameters MUST be sent only in the POST body and the parameters processed MUST be only those from the POST body. When a message is sent as a POST, OpenID parameters MUST be sent only in and processed only from the POST body. Instead of: When a message is sent as a POST, OpenID parameters MUST only be sent in and processed from the POST body. (I feel the first of the two alternative above captures the intention much better. We are aiming to make each clause of this document clear for folks who don't already know what we have in mind, right?) I think Johnny's wording is fine, but if it were to be changed, I would prefer the second of the two alternatives that you proposed. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [security] security hole in signature algorithm
On 11/19/06, Dick Hardt [EMAIL PROTECTED] wrote: By manipulating the return_to parameter, an attacked can impersonate another user at an RP. it's hard to do a careful reading of your message with mhy 2-year-old playing piano in the background, but I don't think I understand your attack. I don't see any KV form strings in your description, and those are the things that get signed. In KV form, the pairs are indeed suffixed with a newline, which is the reason that newlines are not allowed. the x-www-urlencoded string: foo=barbaz=quux looks like: foo:bar baz:quux in KV form. Am I missing something? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Yet Another Delegation Thread
On 10/26/06, Dick Hardt [EMAIL PROTECTED] wrote: * If the IdP-specific identifier is not checked by the relying party's discovery, the IdP MUST do discovery on every request to ensure that it's not making an assertion based on stale information. Which is probably a good idea. :-) If the IdP is sending both identifiers in a signed response, then they both should be valid. Requiring this discovery adds another (redundant) HTTP request to the authentication process, which takes time. I'd like to be able to improve the User Experience by implementing an IdP that would verify the binding occasionally, but not *every time* the user authenticates. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Yet Another Delegation Thread
On 10/26/06, Dick Hardt [EMAIL PROTECTED] wrote: If the IdP is not doing discovery per your previous comment, then compromising the RP's discovery is sufficient hijack a user's identifier, and it likely is easier to compromise an RP then an IdP, and we should move complexity to IdPs to an RP all other things being equal. Compromising a relying party's discovery is sufficient in *any case* to hijack an identifier. The discovery just needs to return a different IdP. Not letting the RP verify *all* of the discovered information adds another place (the IdP) where compromising discovery is a valid attack. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Yet Another Delegation Thread
On 10/25/06, Dick Hardt [EMAIL PROTECTED] wrote: 2) Since the RP has to do discovery on the Claimed Identifier anyway, if it discovers a mapping between the Claimed Identifier and an IdP-Specific Identifier, the RP can send the IdP-Specific Identifier to the IdP and save the IdP from having to repeat discovery. unfortunately that disco information could be modified in route, so the IdP can't trust it I have said this several times already, but THE IDP DOES NOT HAVE TO TRUST THIS INFORMATION. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Yet Another Delegation Thread
On 10/25/06, Dick Hardt [EMAIL PROTECTED] wrote: I have said this several times already, but THE IDP DOES NOT HAVE TO TRUST THIS INFORMATION. Then why send it? Why send which one? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
On 10/19/06, Recordon, David [EMAIL PROTECTED] wrote: The proposal we came up with was within the spec describing what to do if someone were to enter [EMAIL PROTECTED] in a Relying Party's OpenID login form. Here are the past threads that I could find about this issue: 1. http://lists.danga.com/pipermail/yadis/2005-May/000412.html 2. http://lists.danga.com/pipermail/yadis/2005-June/000501.html 3. http://lists.danga.com/pipermail/yadis/2005-July/001113.html 4. http://lists.danga.com/pipermail/yadis/2005-November/001589.html Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID version 1.2 instead of 2.0 (Re: off topic - how many people use OpenID ?)
On 10/20/06, Granqvist, Hans [EMAIL PROTECTED] wrote: I propose renaming the existing OpenID 2.0 work to be OpenID 1.2. (moved over to the specs list, since it hasn't had enough traffic lately) I think it'd be great to put what we have out as OpenID 1.2. That way, the debate and proposals here can continue, while we can start implementing the features that we already know we want and are already specified. This should be good for the people (like me) who want to get a better revision out to users and the community as soon as possible. It should also be good for the people who have changes that they want to make, since changes could be debated solely on their merits and not on how late it is in the specification process. Also, it reserves the number 2.0 for the final version of the protocol wink/ Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Portable Identifier Support Proposal (patch)
As requested [1], I have made a patch to the specification [2] that specifies the two-identifier mechanism for portable identifier support. It's attached to this message. The net effect is adding one line to the source XML file. I hope this proves useful in evaluating the proposal. Josh 1. http://openid.net/pipermail/specs/2006-October/000478.html 2. http://openid.net/svn/listing.php?repname=specificationsrev=70sc=1 (openid.net specifications svn trunk, revision 70) --- svn-track/openid-authentication.xml 2006-10-20 16:08:15.0 -0700 +++ work/openid-authentication.xml 2006-10-20 16:13:05.0 -0700 @@ -132,8 +132,8 @@ referred to as a URL within this document, or eref target=http://www.oasis-open.org/committees/download.php/15376; XRI/eref. An Identifier may be a Claimed Identifier, -Delegate Identifier, IdP Identifier, or Verified Identifier, -depending on context. +IdP-Specific Identifier, IdP Identifier, or Verified +Identifier, depending on context. /t t hangText=End User: @@ -154,7 +154,7 @@ that they own. /t - t hangText=Delegate Identifier: + t hangText=IdP-Specific Identifier: An alternate Identifier that can be included in the discovery response. /t @@ -751,21 +751,17 @@ /t t hangText=Claimed Identifier: -(optional) The normalized Identifier upon which -discovery was performed. The Claimed Identifier is -present unless the End User entered an IdP Identifier -during initiation. +(optional) The identifier that is the subject of this +authentication request. This is the identifier upon +which discovery was performed. /t - t hangText=Delegate Identifier: -(optional) - -The Identifier that the Relying Party SHOULD perform -authentication using. Upon successful authentication, -the Relying Party SHOULD recognize the End User using -the Claimed Identifier. The Delegate Identifier can -only be present when the End User enters a Claimed -Identifier. + t hangText=IdP-Specific Identifier: +(optional) An identifier that allows an IdP to +identify the user of a portable identifier. If no +IdP-specific identifier is present in the discovered +information, the Claimed Identifier is also the +IdP-Specific Identifier. /t /list /t @@ -820,8 +816,8 @@ /t t -An lt;openid:Delegategt; tag (optional) whose - text content is the Delegate Identifier. +An lt;openid:Delegategt; tag (optional) whose text +content is the IdP-Specific Identifier. /t /list /t @@ -928,7 +924,7 @@ t A lt;LINKgt; tag MAY be included with attributes rel set to openid.delegate and href set to the -End User's Delegate Identifier +End User's IdP-Specific Identifier /t /list /t @@ -1362,11 +1358,24 @@ /t t + openid.portable + list style='empty' +t + Value: (optional) The Claimed Identifier. +/t +t + Note: If the portable identifier is not specified, + it is assumed to be the same as the IdP-specific + identifier. +/t + /list +/t + +t openid.identity list style='empty' t - Value: (optional) Delegate Identifier when - available, otherwise the Claimed Identifier + Value: (optional) The IdP-Specific Identifier. /t t Note: If this is set to the special value @@ -1574,11 +1583,25 @@ /t t + openid.portable + list style='empty' +t + t +Value: (optional) The Claimed Identifier + /t + t +Note: If this value is absent, it defaults to the +value of openid.identity. + /t +/t + /list +/t + +t openid.identity list style='empty' t - Value: (optional) The Identifier about which the IdP - is making a positive authentication
Re: Question: multiple IdPs?
On 10/18/06, Recordon, David [EMAIL PROTECTED] wrote: Yeah, the XML file can be based elsewhere. It is especially noteworthy that unless users are combining services, the XRDS document can be the same one that the IdP has issued to go with the IdP-specific URL. For instance, if I want to use another URL with my myopenid account, I just have to add a meta tag pointing to http://josh.myopenid.com/xrds. This means that for non power-users, it's still just as simple as adding one tag to the top of the HTML. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 10/19/06, Josh Hoyt [EMAIL PROTECTED] wrote: when she has control Sorry that I didn't put this all in one message, but: I think it's worthwhile to be aware of what might happen in scenarios where your identifier has been stolen, but it should not have much bearing on which proposal gets accepted, since the attacker will have been able to inflict much greater harm elsewhere. I doubt that the protocol can offer much protection if someone actually gets control of your identifier. For instance, some RPs will offer a way to transition an account from one identifier to another (for e.g. domain names expiring). The attacker can just transition those accounts to an identifier of hers. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Question: multiple IdPs?
On 10/18/06, Dick Hardt [EMAIL PROTECTED] wrote: Thanks Drummond, but what if I am using HTML-based discovery? (that is what I am going to use in my vanity domain, much easier to implement) http://openid.net/specs/openid-authentication-2_0-10.html#html_disco HTML discovery is in there solely for compatibility. From the spec: If a Relying Party locates an IdP using HTML-based discovery, it MUST use OpenID Authentication 1.1 Compatibility when communicating with that IdP. This is because you would otherwise not know whether to use OpenID 1 or 2. Yadis has an explicit type, so it's not a problem. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Summarizing Where We're At
On 10/17/06, Dick Hardt [EMAIL PROTECTED] wrote: * Authentication Age - Re-proposed today adding clarity in motivation, general consensus is needed to add to specification. -1 There is no reason for this to be in the core. I could make more arguments about it, but I'll stop there, unless there is consensus that it should go in the core. Would you provide a reason to counter my justification: http://openid.net/pipermail/specs/2006-October/000433.html Your vote is a -1, not a zero, so I would like to understand why. The way that I understand your argument is it has something to do with authentication, so put it in the core spec. Features should be in an extension if it can be, so that the spec is easier to understand, implement, and extend. Especially if there is not consensus. I am also not convinced that it's technically the right way to accomplish what you're aiming to accomplish, but I am not going there unless you can convince enough people that the use case is in scope for core OpenID authentication. Also: http://openid.net/pipermail/specs/2006-October/000206.html Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Summarizing Where We're At
Here are my reactions to what's outstanding: On 10/15/06, Recordon, David [EMAIL PROTECTED] wrote: * Request Nonce and Name - Has been partially implemented, openid.nonce - openid.response_nonce, no agreement on the need of a request nonce specifically, rather discussion has evolved into allowing a RP to pass appdata like in Yahoo's BBAuth. No formal proposal on the table yet, thus will not be included in this version. Take no action * Authentication Age - Re-proposed today adding clarity in motivation, general consensus is needed to add to specification. -1 * Remove setup_url - Little discussion and no general consensus to do so. Rather seems asking for feedback from checkid_immediate implementers on the parameter would be beneficial at this time. +1 * Consolidated Delegation Proposal - Very active discussion, the only proposal I'm willing to stall the spec for. Seems very important a strong conceptual model is created at this time. -0 on status quo (draft 10) +0 on single-identifier +1 on two-identifier * Change Default session_type - Proposed, no discussion yet. Will address in separate message * Bare Request - Proposed, no discussion yet. -0 (YAGNI) Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 10/16/06, Marius Scurtescu [EMAIL PROTECTED] wrote: In this case you are better off opening a separate account with this or some other IdP. The current delegation model will not protect you at all. The delegate tag is in a publicly accessible Yadis document. I agree that anonymity is an important feature, but the current solution gives you only a false sense of security. What's the current solution that you're talking about? As far as I know, no one is suggesting portable identifiers as a way to achieve anonymity. I also do not think anyone is suggesting that IdP-driven identifier selection will make you anonymous *to the IdP.* You are correct that in order to avoid anyone knowing the identifiers that you use, you have to have separate accounts on different IdPs. I can't come up with any way that the protocol can help (or impede!) the user with achieving this. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Notes From Draft 10
On 10/16/06, Marius Scurtescu [EMAIL PROTECTED] wrote: Sorting of unicode strings while not terrible hard it is not trivial either. Why bother? The list of signed fields gives an explicit ordering, this is good enough IMO. Sorting by UTF-8-encoded octet sequence is easy. Why would be an alphabetically sorted list better? Just so that there is an obvious one way to do it, so that it's easier to get right, if I understand David's motivation. It's also easier to make clear in the spec. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Notes From Draft 10
On 10/16/06, Marius Scurtescu [EMAIL PROTECTED] wrote: Just so that there is an obvious one way to do it, so that it's easier to get right, if I understand David's motivation. It's also easier to make clear in the spec. If ordering is not important then you are guaranteed to get it right. But ordering *is* important whether a specific order is prescribed or not. The same ordering has to be used when the signature is generated and when it is checked. The spec could recommend alphabetical ordering, but I don't see the need for a must. If it's not a MUST, then it doesn't clarify or simplify the procedure, because it could still be any order. Again, I don't care very much about making this change. Unless David stands up for it, I'm going to drop it. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 10/13/06, Drummond Reed [EMAIL PROTECTED] wrote: So whether it's in the spec formally or not, I don't really care. But the spec MUST contain details on the precautions a RP should take. Yup.(Got that, editors?) http://openid.net/specs/openid-authentication-2_0-10.html#anchor38 Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 10/13/06, Chris Drake [EMAIL PROTECTED] wrote: DR CASE 1: the protocol supports only IdP-specific identifiers and no portable DR identifiers. DR RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. Please explain? If I've got an OpenID URL (eg: my vanity domain), I can transfer this via DNS (or just update my OpenID LINK). If I've got an i-name, I can transfer this too. Where's the lock in ? This is true assuming that IdPs have uniform support for registering an identifier that it did not issue. OpenID 1 addressed this in its architecture. In OpenID 1, the identifier does not even have to be registered with the IdP. The proposed changes alter this arrangement. In the 2-identifier proposal, the IdP does not need to support registering identifiers, but it can be aware that a third-party identifier is being used. In the one-identifier proposal, the IdP is solely responsible for being aware of the arrangement. I do not think the success of the protocol rides on this decision, but I think it's important to understand, and understand the implications of the choice that is made. In many ways, the spirit of OpenID has been to empower the user above all. OpenID 1's delegation is consistent with that. I do not believe the RP needs to know the IdP-specific identifier ever (worse: I think it should never be allowed to know it, or even be allowed to see it!). Why not? Yes - we need 2 identifiers - but from the point of view of the specs - the OpenID protocol really only needs to deal with one. See above. There seem to be a lot of people on this list who want to hate and loathe the IdP, and grant all power to the RP. I do not understand this reasoning: our users will select the IdP they trust and like, then they will be using a multitude of possibly hostile RPs thereafter: the reverse is simply not true. Where is power being granted to the RP? It has pretty much none. It *does* have responsibility, but only as much as is necessary to make the protocol work. Can we not adopt my earlier suggestion: just ensure OpenID can permit IdP-initiated logins. This permits every scenario of portability (and privacy) that everyone wants, without us having to continue to debate it ? Huh? How is IdP-initiated login related to privacy or portability? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: RP attack vector - why two identifiers are redundant
On 10/14/06, Dick Hardt [EMAIL PROTECTED] wrote: Since the request is not signed and flows through the user, the IdP does not know the request message has not been modified. If the IdP assumes the two identifiers are bound, then a malicious user can pretend to be a different user from the same IdP to the RP. This presumes the IdP is using an IdP identifier and the RP is using an RP identifier and the binding is assumed by sending both. Therefore, the IdP MUST make sure the two identifiers are linked, so sending both is redundant for the IdP. The relying party knows both identifiers from doing discovery, and it must check to make sure they match what is in the assertion. Since the relying party MUST make sure it matches, the IdP doesn't have to. I would say that the IdP SHOULD check to make sure it's valid, but it's not strictly required. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10/13/06, Marius Scurtescu [EMAIL PROTECTED] wrote: The IdP is issuing a signed assertion about these identifiers, I would assume the IdP to check the link between these identifiers. Sending two identifiers does not *prevent* the IdP from checking to make sure they match. What if a bad RP sends an auth request with a mismatched set and then re-posts the response to some other RP? I am sure someone will figure a way to exploit this. It is, and must be, the relying party's responsibility to ensure that the information in the response matches what is discovered. This is true regardless when portable identifiers are used and when they are not. It is true for all of the proposed delegation mechanisms. It is really one of the fundamental elements of OpenID. A response from an IdP is meaningless until it is compared with the discovered information for the identifier in question. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] request nonce and name
On 10/12/06, Marius Scurtescu [EMAIL PROTECTED] wrote: If passing through all unrecognized parameters can cause problems then there could be a special namespace for this purpose. For example, all parameters with names starting with openid.pass. should be ignored by the IdP and passed back to the RP. Yahoo Browser-based authentication [1] has a single parameter called appdata (that you can find in [2]) that is used for this purpose. This seems general enough to me. Josh 1. http://developer.yahoo.com/auth/ 2. http://developer.yahoo.com/auth/user.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
On 10/12/06, Marius Scurtescu [EMAIL PROTECTED] wrote: The protocol does not need to touch on IdP-specific identifiers (aka delegated identifiers) at all IMO. If there is a specified mechanism that must be supported for using a portable identifier, all IdPs will support it, so identifiers will actually be portable. You'd have a very difficult time trying to get people here to remove portable identifier support from the OpenID protocol. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote: RP user id is the identifier by which the relying party knows the user. This is the one that the user gave the RP? For URL identifiers, it is the supplied identifer, normalized, after following redirects. In essence, it's the user's chosen identifier. For XRI identifers, it's the canonical ID (i-number). openid.identity is the IdP user id. Where did this come from? When using delegation, it's the delegate value. Otherwise, it's the same as the RP user id. It is identical to the way that the value for openid.identity is currently used in OpenID 1 and the current draft of OpenID 2. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote: My proposal was pretty much your proposal with a couple tweaks (sorry, I should have listed these to make it clearer) - the IdP can return a different identity then the one the RP sent over I question whether this is something we want to encourage. I think it's a separate issue from the delegation mechanism. If the user wants to choose an identifier, he'll use IdP-driven selection instead of entering an identifier. I don't feel strongly about this, but I do feel strongly that this should be decoupled from the delegation discussion. - since the delegate is only used by the IdP, the spec can be simplified (in fact, this can be out of band of the spec since it is a protocol between the user and the IdP, the RP is not involved) This was exactly my original proposal: A request for a delegated identifier and a request for a non-delegated identifier would be the same for the relying party, and the final, verified identifier would always be included in the request/response. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote: The IdP cannot trust the RP's discovery. The IdP will have to make sure that the IdP is authoritative for the identifier regardless. The IdP doesn't have to trust the relying party's discovery. The IdP *can* make sure that it is authoritative for the rp_user_id, but if it isn't, the login will fail anyway. Only a malicious or broken RP will make a request with an identifier that does not point to that IdP. A malicious or broken RP does not need a meaningless assertion in order to pretend to have authenticated a user. The relying party is required to validate the assertion by doing discovery anyway, and there is no case for sending an identifier that does *not* delegate to that IdP, so why make the IdP do discovery again? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10/9/06, Recordon, David [EMAIL PROTECTED] wrote: In terms of openid.display, shouldn't the IdP greet the user in whatever manner it uses? Thus if the user has an account on the IdP, the IdP should always greet the user in the same manner with it. Seems like both a usability, phishing, and potential XSS issue if the IdP greets the user with a string from the RP. Am I just missing something there? The display name is only useful for XRI synonyms. Basically, =foo and =bar could both be tied to the same i-number. Doing resolution on =foo and =bar will yield the same canonical id, which means that they represent one logical entity. Drummond wants the display name to tell the IdP *which* synonym the user entered at the RP so that the IdP can present that same synonym in the UI, since the canonical id is both the IdP user identifier and the RP user identifier, but is not user-friendly (=!1234.1234.1234.1234) For URIs, the display name *must* be the same as the RP user identifier, because there is no other value is verifiable by the IdP. Does that explanation help? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Separate Public Identifier from IdP Identifier
On 10/6/06, Martin Atkins [EMAIL PROTECTED] wrote: * The IdP returns a document naming its authentication endpoint (in the URI field) and a special anonymous token as openid:Token. openid:Token may be the same as the public identifier from the previous step, but this is not required. Anonymous is not a good thing to call this. What IdP-driven identifier selection does is let the IdP help the user choose an identifier. In no way is the response any more anonymous than an identifier that was typed in by the user. It is true that one of the motivations for this feature is the great improvement in the user experience for site-specific identifiers, but the IdP could just as well return a cross-site identifier for the user. Sorry to go on about terminology, but I think it's important for understanding what's really going on. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Delegation Proposal Amendment
I'd like to amend my proposal for changing the delegation mechanism: Revised Proposal As it stands, openid.identity is the identifier by which the IdP knows the user. There is no parameter by which the RP knows the user. I propose to add a field called openid.rp_user_id in checkid_* and id_res that defaults to openid.identity if it is missing. This field is the identifier by which the relying party knows the user. This is the identifier on which discovery was performed by the relying party. The name openid.rp_user_id is not the best, but it *is* very specific. Other suggestions welcome. Benefits This proposal retains the current behaviour in terms of who is responsible for discovery and verification. It makes the messages between the RP and IdP more explicit. It is completely backwards-compatible. IdP-driven identifier selection can now return a delegated identifier (if the user wishes to do so). Drawbacks = The IdP now has knowledge of the identifier that the user entered at the relying party. Discussion == I think there is general agreement that the protocol messages on the wire can lead to confusing results. I also think that it's easy to get the relying party implementation wrong because it has to keep track of state to ensure that the user gets the right identifier. I don't think that most relying parties will have a problem keeping state, but I think it's not a good idea to make proper behavior (using the right identifier) *depend* on the relying party's implementation of state storage. This proposal is similar in spirit to Martin's proposal, in that it acknowledges that delegation is not really a special case. The main difference is that (a) it is obvious from the protocol messages what is going on and (b) discovery is entirely unchanged. Related threads === Original proposal: http://openid.net/pipermail/specs/2006-September/02.html Brad's explanation of openid.delegate: http://openid.net/pipermail/specs/2006-October/000182.html Regarding the purpose of delegation: http://openid.net/pipermail/specs/2006-October/000170.html Martin's similar proposal: http://openid.net/pipermail/specs/2006-October/000216.html Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation Proposal Amendment
On 10/6/06, Granqvist, Hans [EMAIL PROTECTED] wrote: Can you propose this in terms of diffs to the current draft so it is glaringly obvious what the proposal means? Sure. Also, I think this diffs to current draft can be most useful for all proposals as it cuts through the various semantic clouds we all have hanging over our heads ;) Do you mean literal Unix-style diffs or a human-readable set of changes to section numbers? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: What is delegation for? (was Re: Wrapping Up Proposals)
On 10/2/06, Johannes Ernst [EMAIL PROTECTED] wrote: It appears to me that OpenID should be able to do the same thing that we've been doing in LID: one-way nonces. This is the way that it's currently written up in the spec. When I wrote it up I had LID nonces in mind. The current proposal is to have *two* nonces - one for the request and one for the response. I bet there are good arguments for being able to identify both the request and the response individually, but I can't come up with any. Why do we need a response nonce if there is a request nonce? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: One last plea: fix problem with delegate terminology
On 10/2/06, Drummond Reed [EMAIL PROTECTED] wrote: 2) In OpenID Authentication 2.0, define a new term to uniformly describe the concept of equivalent OpenID identifiers, i.e., identifiers that are both controlled by the same real-world authority (end user), and are mapped together to give the end-user control over the identifier they present to an RP vs. the identifier by which they authenticate to an IdP. This seems about the same as the trust_root - realm change. +0 from me. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: featuritis for existing form handlers (was: Sorting fields in signature generation)
On 9/27/06, Dick Hardt [EMAIL PROTECTED] wrote: Additionally, as we have researched what is contained in registration forms, this use case does not look like it will be that common. Many forms have some site specific data, and I am now thinking that this is not a very useful feature. I'm glad that we're in agreement on this. wrt. passthrough data Many sites preserve state between forms with hidden values. Given that registration on a site will likely ask the user for some site specific data, some sites will likely be maintaining state through hidden fields, and it will be easier for them to integrate OpenID if the RP can send values that it gets back later on. Given this is not explicitly in the spec, we can write it up. Would welcome feedback on passthrough data. This model is only necessary for sites that do not support sessions, right? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Request for comments: Sorting fields in signature generation - Call for votes
On 9/27/06, Marius Scurtescu [EMAIL PROTECTED] wrote: please keep in mind that we are not asking for some fancy new technology or feature, just conformance with a very basic an wide spread convention of handling parameters in HTTP/HTML. As Kevin pointed out, we are not working on the HTTP/HTML form processing specification. We are working on an authentication protocol. Restricting the protocol to forbid multiple parameters with the same name does not break conformance with anything. I think that we have discussed the majority of the technical issues regarding multiple parameters with the same name. I could respond to your individual points, but I don't think that would get us any closer to agreement. Can we get +1/-1 on multiple parameters with the same name from people without @sxip.com or @janrain.com e-mail addresses? Clearly, we (JanRain) are -1. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Request for comments: Sorting fields in signature generation
On 9/27/06, Johnny Bufu [EMAIL PROTECTED] wrote: Huh? I don't see anything in that section about a requirement to echo back parameters. Not a requirement, but I read the second paragraph as implying they can/could be used. An IdP is not forbidden from echoing back any unknown parameters it got, but no OpenID implementation has ever done this, to my knowledge. I expect that unless the specification said otherwise, applications would ignore unexpected parameters. As far as I can tell, this is standard behavior on the Web. If that weren't so, then why is there the openid. prefix to the parameters in some of the messages? The reason that the parameters have openid. at the beginning is so that it is clear that they are part of the OpenID protocol message and not intended to be operated on by the application that is processing the OpenID request. Basically, to reduce the likelihood of name collisions with parameters that the application uses. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Request for comments: Sorting fields in signature generation
On 9/26/06, Barry Ferg [EMAIL PROTECTED] wrote: The signature generation algorithm specifies that the fields to be signed be ordered in byte order form. It seems to be implied that the ordering is based on using the field names as sorting keys I think the real topic of this discussion is whether or not multiple parameters with the same name should be allowed by the specification. I *strongly* prefer tightening the specification by *disallowing* duplicate parameter names. PHP is one environment in which the implementation will be problematic, but other common environments (e.g. Rails) do not easily support this idiom. There is *no deployed code* that depends on duplicated parameter names, and I'd like to keep it that way. Keep it simple if possible. I agree that the language in the specification should be clarified so that the sort order is fully explicit. I would resolve this issue by stating that the pairs must be sorted by key. On another note: Pass-through (or echo) parameters and potentially some OpenID extension parameters may include fields with multiple values in order to communicate arrays of data, etc. Attribute exchange and other extensions can *easily* be designed not to require multiple parameters with the same name. Pass-through parameters are *not part of any OpenID specification.* Even if they were, I don't think it would be too great of a restriction to disallow duplicate parameter names. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Request for comments: Sorting fields in signature generation
On 9/26/06, Marius Scurtescu [EMAIL PROTECTED] wrote: Pass-through parameters are *not part of any OpenID specification.* They are not, but in order to be able to pass them through you have to be able to deal with them. Also, you may have to sign them as well. No one has written a proposal for pass-through arguments and it's not in any specification, so it's hard to answer your objection. If someone were to propose adding pass-through parameters to the specification, I would argue that: a) Including the pass-through arguments in the OpenID signature is not necessary (or constructive!) b) It is quite reasonable to restrict them to only one value per parameter name. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
