Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote: 7.3.3. HTML-Based Discovery A LINK tag MUST be included with attributes rel set to openid2.provider and href set to an OP Endpoint URL A LINK tag MAY be included with attributes rel set to openid2.local_id and href set to the end user's OP-Local Identifier Could somebody please enlighten me as to what's wrong with leaving those as openid.server and openid.delegate respectfully (i.e. backward-compatible)? The new attribute values are needed in order to signal an OpenID 2 provider. But you bring up a good point, backwards compatibility can be easily broken here. 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. Probably the spec should say this in section 7.3.3 and give clear instructions regarding OpenID 1.1 tags. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0Authenticationspecification
On 18-May-07, at 11:09 AM, Recordon, David wrote: Hey Marius, Good point, committed a patch so please review! :) http://openid.net/svn/diff.php?repname=specificationspath=% 2Fauthentica tion%2F2.0%2Ftrunk%2Fopenid-authentication.xmlrev=325sc=1 That was fast :-) Looks good, but I would add to that a sentence stating that you SHOULD put both sets of tags when editing HTML pages in order to be backwards compatible. Thanks, Marius Thanks, --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marius Scurtescu Sent: Friday, May 18, 2007 10:48 AM To: Dmitry Shechtman Cc: 'OpenID specs list' Subject: Re: Final outstanding issues with the OpenID 2.0Authenticationspecification On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote: 7.3.3. HTML-Based Discovery A LINK tag MUST be included with attributes rel set to openid2.provider and href set to an OP Endpoint URL A LINK tag MAY be included with attributes rel set to openid2.local_id and href set to the end user's OP-Local Identifier Could somebody please enlighten me as to what's wrong with leaving those as openid.server and openid.delegate respectfully (i.e. backward-compatible)? The new attribute values are needed in order to signal an OpenID 2 provider. But you bring up a good point, backwards compatibility can be easily broken here. 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. Probably the spec should say this in section 7.3.3 and give clear instructions regarding OpenID 1.1 tags. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 18-May-07, at 11:45 AM, Josh Hoyt wrote: 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. Good point. I'm sure that this will break a few implementations, checking openid4java right now... Thanks, Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: encoding newlines in attribute values
On Wed, 2007-18-04 at 23:25 -0700, Douglas Otis wrote: On Apr 18, 2007, at 8:31 PM, Marius Scurtescu wrote: Base64 encoding is a pretty good candidate for binary data, but you cannot apply the same encoding to text fields. RFC4648 URL and Filename safe Base 64 Alphabet might be a good choice. Applying base64, or similar encoding appropriate for binary data, to text fields has two drawbacks: - renders the field unreadable Binary data is often unreadable. True, but text is readable and ideally it should stay like that. - increases the size of the field Base 64 increases the size of the encoded element by about 30%. URL-encoding has the advantage that probably all web frameworks will have functions to encode and decode this format. URL-encoding increases the size of the encoded element by 300%. Only unsafe characters are encoded, not the whole string. Not sure how UTF-8 changes any of this. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: encoding newlines in attribute values
On 19-Apr-07, at 7:29 AM, Rowan Kerr wrote: On 18-Apr-07, at 9:47 PM, Johnny Bufu wrote: The core spec doesn't allow newline characters (\n) in any openid.* values. Currently, Attribute Exchange doesn't specify a way to encode newlines in attribute values. Every indirect OpenID message would seem to be already url-encoded by the browser, or server as post data .. so \n = %0A (i.e. application/x-www-form-urlencoded mime type) Do we need a pre-url-encode encoding, or can we rely on browsers to do the right thing... I suppose it's helpful to spell it out for non- browser agents that want to pass OpenID messages. 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. If we want to define sending binary data in OpenID messages, maybe we should leverage multipart/form-data. Same as above, need to encode for signatures to work. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Notes From Draft 10
On 16-Oct-06, at 2:44 PM, Josh Hoyt wrote: On 10/16/06, Recordon, David [EMAIL PROTECTED] wrote: 6.1 Signed List Algorithm [...] I'm thinking it would make sense to change this algorithm to first alphabetically sort the arguments to make it very clear in terms of ordering. I think it's a good idea to say that the signed list MUST be generated by the IdP in that order. Then signature *verification* is compatible with OpenID 1's algorithm. Unless there is objection, I'll do this. 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. Why would be an alphabetically sorted list better? Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Notes From Draft 10
On 16-Oct-06, at 3:13 PM, Josh Hoyt wrote: 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. This is not the same as alphabetical ordering though. It could be the same in most cases, and probably it is for the current set of defined open id parameter names. For alphabetical ordering you have to get into locales and collations. 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. If ordering is not important then you are guaranteed to get it right. The spec could recommend alphabetical ordering, but I don't see the need for a must. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
On 13-Oct-06, at 12:20 PM, Drummond Reed wrote: Marius wrote: I was suggesting that portability can be resolved between the user and the IdP. I cannot see how the protocol can help this by passing two identifiers. And if only the portable identifier is passed then there is no need to mention the IdP-specific identifier. Marius, see the analysis at http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, now updated to include Josh's lastest thinking from http://openid.net/pipermail/specs/2006-October/000357.html. In sum, not being able to send the IdP-specific identifier: a) forces the IdP to redo resolution, which is unnecessary and slows performance, and Not necessarily. When you register with the IdP most likely you will claim all your portable identifiers with this IdP, so the IdP knows about them. With XRI i-name/i-number infrastructure that's neither practical nor desirable. With XRIs, users control their own synonyms, i.e., I can register a delegated i-name within a specific community (for example, at @example.community I could register @example.community*drummond) and then point that at my personal i-name (=drummond.reed) and the IdP for =drummond.reed will never know -- and doesn't need to know. I could go to any RP and login in as @example.community*drummond, the RP will resolve this to =drummond.reed (through the way XRI resolution automatically handles reference processing -- let me know if you want more info about this), and end out storing the CanonicalID i-number for =drummond.reed (which is =!F83.62B1.44F.2813). I don't see the point if hiding some of your portable identifiers (@example.community*drumond) from your IdP and at the same time disclose it to all the RPs you deal with. If you are using a portable identifier and you have an IdP then it seems normal to me to trust your IdP to know your portable identifier. I would be more nervous about all the RP knowing my IdP issued identifier. What is not practical about registering your portable identifier with your IdP? b) prevents the protocol from being stateless. How? The RP deals only with the portable identifier and this is the only thing the IdP sends back. Why do you need state? It follows from the above. But this is so important that I'm going to send a separate message about it. I can't see it, sorry. If the RP is indexing your account based on your i-number then it could send your i-number to your IdP for authentication, but it can also send your i-name. I don't think it matters. The IdP should know both and it can lookup your account with any of them. What state must the RP save? The RP has both your i-name and i-number as well (unless you are registering), so when the response comes back it can look you up with any. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 13-Oct-06, at 12:59 PM, Drummond Reed wrote: Yesterday we established consensus that with OpenID, identifier portability is sacred. Today I'd like to establish consensus on the following postulate: To achieve identifier portability in OpenID, it MUST be possible for the RP and the IdP to identify the user using two different identifiers: an identifier by which the RP knows the user (the portable identifier), and an identifier by which the IdP knows the user (the IdP-specific identifier). I would submit that if this postulate is true, then OpenID Authentication 2.0 requires two identifier parameters because if the protocol only allows sending one, then: 1) If the RP sends the IdP-specific identifier, the RP must keep state to maintain mapping to the portable identifier (bad), and I agree with that. 2) If the RP sends the portable identifier, an IdP is forced to do a resolution a second time after the RP has already done resolution (bad). No, the IdP is not forced to do a resolution. The IdP already knows that. OTOH, if the postulate is false, then a case can be made for OpenID Authentication 2.0 having just one identifier parameter. PROOF CASE 1: the protocol supports only IdP-specific identifiers and no portable identifiers. RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. Agreed. CASE 2: the protocol supports only portable identifiers and no IdP- specific identifiers. RESULT: IdP is forced to know and store all portable identifiers for a user, including identifiers for which the IdP is not authoritative, and users Why would the IdP need to know identifiers over which it is not authoritative? would be forced to register all their portable identifiers with their IdP, and to update these registrations every time the user adds or deletes a portable identifier. Highly undesirable if not impossible. I don't see this as undesirable but as necessary. If I have a portable identifier and I configure it to point to some IdP for authentication it only makes sense for the IdP to know about the identifier as well. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 12-Oct-06, at 11:40 PM, Drummond Reed wrote: Drummond wrote: Since the RP has to do discovery on the i-name, the RP already has the i-number (CanonicalID). Further, as explained in previous threads, the CanonicalID is the primary key the RP wants to store for the user, not the i-name, because the i-number is forever while the i-name could change. The RP is also motivated to send the i-number to the IdP for the same reason that the RP is motivated to send the delegate URL (if available): to increase performance by saving the IdP from having to re-resolve the i-name (in the XRI case) or original URL (in the URL case). Dick wrote: Won't the IdP will still have to resolve the i-name? The IdP can't trust the RP, or know that the i-name and i-number are really linked unless it checks itself. There are no trust issues involved with the IdP using the identifiers sent by the RP. The RP is relying on the IdP, not vice versa. If the RP sends the wrong identifiers, it's fooling no one but itself. Thus the IdP has no reason to re-resolve (and good performance reasons not to). The IdP is issuing a signed assertion about these identifiers, I would assume the IdP to check the link between these identifiers. 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. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] request nonce and name
On 12-Oct-06, at 12:10 PM, Recordon, David wrote: We thus believe that any state tracking needed by a stateless RP must be maintained as GET parameters within the return_to argument. In the case of a stateful RP, it can either do the same thing, or store state via other means such as using a session id within a cookie to reference database data. So basically the query string of the return_to parameter is used to implement pass through parameters. Why not require that unknown parameters be passed through? This way the return_url is clean and it can be persisted (for bookmarking for example) and there are no size limitations. 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. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
On 12-Oct-06, at 10:29 AM, Josh Hoyt wrote: Both portable and IdP-specific identifiers -- Include both the portable identifier and the IdP-specific identifier in the request and response ([4]_ and [5]_):: openid.identity = http://my.idp.specific.url/ openid.portable = http://my.portable.url/ The relying party is still responsible for checking to make sure that the IdP-specific identifier that is returned matches what is discovered from the portable identifier, but since it is included in the authentication response, it is not necessary for the relying party to maintain this state, and an authentication response is meaningful without the context of the request. The messages in this proposal are very explicit about what is going on. The only way in which this differs from OpenID 1 is that the portable identifier is also included in the response. The meaning of the openid.identity parameter is identical to its meaning in the OpenID 1 protocol (the IdP-specific identifier). Not sure why are both identifiers needed? The RP cares only about the portable one, right? Is backwards compatibility the only reason? Portable identifier only This option makes sense to me. The protocol does not need to touch on IdP-specific identifiers (aka delegated identifiers) at all IMO. This is really an IdP implementation detail. The only important point seems to be the fact that identifiers are portable and IdPs should allow users to move them around. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] request nonce and name
On 12-Oct-06, at 5:07 PM, Josh Hoyt wrote: 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. True, even one single pass through parameter should do. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Separate Public Identifier from IdP Identifier
On 5-Oct-06, at 3:36 PM, Recordon, David wrote: Conceptually I think I like this model. It does seem easier to understand. Other thoughts on this? I am still not sure how the delegated identifier is useful. I did miss the earlier discussions, so probably I don't have enough background on this. The only problem it seems to solve is that of vanity identifiers. Switching IdPs where you had an IdP issued identity for the original IdP does not seem to be possible, you have no control over that original identity so you cannot use it anymore. If you had a vanity identity with the original IdP then switching only means pointing your vanity identity to the new IdP. So it really boils down to controlling your vanity identity. Instead of dealing with vanity identities using the delegate tag why not let the IdP manage your vanity identities? When you register with an IdP you should be able to register additional vanity identities, as many as you want. You have to prove to the IdP that you control them, but this is a different problem (I'll get back to this). This is similar to domain names (identities) and hosting companies (IdPs). You can configure your domain to point to a different hosting company (this is like editing your Yadis document to point to another IdP). If you don't care about your own domain then you can get cheap or free hosting but at some URL controlled by the hosting company (these would be the IdP issued identities). Most of the sites you deal with are RPs, not IdPs. Also, you would trust more your IdP then any RP. The link between multiple vanity identifiers will be know only to the IdP, the RPs will not know this. Now, how would the IdP check that you indeed control a vanity identity? First of all, you have to point to that IdP. Second, the IdP will check that no one else claimed this vanity identity. So unless there is an attempt by someone else to claim the same identity the IdP can take your word for it. If it wants to go one step further (or if there is a conflict) then the IdP can ask you for more proof that you own this identity: - it can send a verification email associated with the domain of this identity (if it is a root domain) - it can ask you to place a special file under this domain/path - it can ask you to add special headers in the HTML page of this identity - it can ask you to add a special field into the yadis document (and this field could be a replacement for the delegate element) Does this make sense? What am I missing? Thanks, Marius --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, October 04, 2006 11:34 AM To: specs@openid.net Subject: [PROPOSAL] Separate Public Identifier from IdP Identifier Currently the conceptual model is that each user has a public (that is, presented to RPs) identifier, but can optionally create additional identifiers which delegate to the real identifier. The delegate functionality has several purposes, including: * Vanity identifiers on personal domains while letting someone else do the hard work in running the IdP. * Ability to switch IdPs without losing identity However, experience has shown that the above model is often difficult to grasp for those new to OpenID. This proposal is really just a set of terminology changes and an alternative conceptual model that aim to make the delegate functionality easier to understand. It does not change the mechanism of delegation at all, though it does change the discovery protocol. I've placed the full proposal on the OpenID wiki: http://www.lifewiki.net/openid/SeparateIdentifierFromIdPToken ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs