Re: Auth 2.0 spec errata regarding delegation vs. directed identity
Arrgh! I'm horrible with names. See below for corrected text. On Wed, May 21, 2008 at 4:03 PM, John Ehn [EMAIL PROTECTED] wrote: Josh, 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: * Run discovery against the Claimed Identifier (or use the cached response from a previous discovery), thereby determining the Local Identifier and endpoint URLs * If a Local Identifier is discovered, compare the Local Identifier with the openid.identity value in the assertion and verify they are the same - if they do not match, then authentication validation MUST fail * If a Local Identifier is not discovered, compare the Claimed Identifier with the openid.identity value in the assertion and verify they are the same - if they do not match, the Claimed Identifier MUST be ignored, and the value of openid.identity MUST be used instead I does not state this, though. It is very much open to interpretation. Normative text needs to be very specific. If you make a vague statement like you MUST verify what was received against what you already know, it can be interpreted very differently depending upon who is reading it. Honestly, my client implementation did not perform this check until Martin made mention of it on this list. From what Martin states, it appears there several implementations are affected by this issue, which follows that the specification does not read as clearly as it should. Therefore, I suggest taking some action to correct the problem. Sweeping this under the carpet will cause more harm than good. Thank you, John Ehn extremeswank.com On Wed, May 21, 2008 at 3:20 PM, Josh Hoyt [EMAIL PROTECTED] wrote: 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Google OpenID is now live
I agree. I think this is an excellent technology demonstration, but it is a third-party, not Google, that is enabling the ID. John 2008/4/9 Immad Akhund [EMAIL PROTECTED]: When Google eventually does make a proper OpenID provider all the OpenIDs provided by openid-provider.appspot.com would not match. Would get very confusing apart from advanced users that understand the distinction. Immad On Wed, Apr 9, 2008 at 12:49 PM, Paul Madsen [EMAIL PROTECTED] wrote: I expect Google might have a (legal) opinion on characterizing this application as 'Google OpenID' I think I'll wait for Google itself to enable my Gmail as an OpenID. paul Vinay Gupta wrote: http://openid-provider.appspot.com/ Somebody used their app hosting service and implemented an OpenID provider. That kind of changes things, doesn't it? Vinay -- Vinay Gupta - Designer, Hexayurt Project - an excellent public domain refugee shelter system Gizmo Project VOIP: 775-743-1851 (usually works!) http://hexayurt.com/ Cell: Iceland (+354) 869-4605 Skype/Gizmo/Gtalk: hexayurt People with courage and character always seem sinister to the rest Herman Hesse ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.9/1365 - Release Date: 4/8/2008 7:30 AM -- Paul Madsene:paulmadsen @ ntt-at.com NTTp:613-482-0432 m:613-282-8647 aim:PaulMdsn5 web:connectid.blogspot.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Cell: +1 617 460 7271 Skype: i.akhund Blog: http://immadsnewworld.com Clickpass, CTO ___ 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: Difference between 1.0 and 1.1
Anatoly, 1.0 was an informal specification, so it was prone to ambiguities. 1.1solved the majority of these problems, as it is clearer which aspects of the specification are optional and mandatory. As far as I know, OpenID 1.1 is what all consumers should be supporting at this point. Thanks, John Ehn extremeswank.com On 3/12/08, techtonik [EMAIL PROTECTED] wrote: Hi. What is the difference between OpenID authentication version 1.0 and 1.1? We need some arguments to switch preferable backwards compatibility scheme from 1.0 to 1.1 in Drupal. Looks like there is no way to detect which version of these two is used in case of HTML delegation and this causes problems between Drupal 5 and Blogger, because Drupal chooses 1.0 in this case. WBR, -- --anatoly t. ___ 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: Difference between 1.0 and 1.1
On 3/12/08, techtonik [EMAIL PROTECTED] wrote: So, if I understand correctly there is no way for consumer to detect which version - 1.0 or 1.1 is used in HTML delegation case, because delegation tags are the same, i.e. link rel=openid.server href= http://www.livejournal.com/openid/server.bml; link rel=openid.delegate href=http://exampleuser.livejournal.com/; so in my case Drupal consumer decides that either 1.0 or 1.1 version of specification is used and makes a request to OpenID server with openid.nsset to either http://openid.net/signon/1.1; or http://openid.net/signon/1.0;. But 1.1OpenID server doesn't know anything about openid.ns, because it was added only in 2.0 Therefore server fails to authenticate and this should be considered a bug in consumer, which should not send openid.ns at all. If everything above is right then where is the logic and what are the reasons for consumer to send openid.ns= http://openid.net/signon/1.1; at all? Thank you. Just to add my 2 cents, that namespace was introduced so you can discover an OpenID Server using XRI. That would be in the XRDS document to advertise that the OpenID Server supported a specific version of the spec. Since OpenID 2.0 incorporates the XRI feature (which was a sort of third-party add-on to the OpenID 1.x spec), that namespace is still used. But, like James said, you shouldn't use openid.ns with 2.0 anyway. Thanks, John Ehn extremeswank.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Login Federation
Sounds like fun. But I don't think I have the energy to go through a process like that to get a extension spec registered. If anyone wants to take the spec and run with it, they are welcome to. Thanks, John On 2/20/08, Nat Sakimura [EMAIL PROTECTED] wrote: Actually, there seems to be. I was reading through the documents today and found about it. http://openid.net/ipr/OpenID_Process_Document_(Final_Clean_20071221).pdf Basically, 1. Contributors for the new spec Sign the Contribution Agreement and gather more than five proposed WG members. 2. Apply for a new Work Group to specs@openid.net = This needs to fulfil certain requirement. 3. Get the approval from the Specification Council which is composed of two board members and five current and ex-editors (Eligible Editors). Who are the members of the current Specification Council? 4. Start WG. Spec needs to go through three stages process: Draft - Implementors Draft - Final Basically, WG needs concensus to propose the spec to be implementors draft etc. to the members.After certain review period, members get to vote. The quorum is greater of 20% of OIDF members or 20 OIDF members. Regards, =nat Brett Carter wrote: John Ehn wrote: Sounds good. I'm working on a draft. Once it's in a readable state, I'll post it for comments. Thanks! Is there a formal process for submitting a proposal yet? Or are we just going with RFC format for now? -Brett ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Nat Sakimura (=nat) Nomura Research Institute, Ltd. ___ 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: Login Federation
During the session cookie request, we are notifying the RP of the isLoggedIn attribute. The RP will already have this value (along with the matching OpenID Identifier) because it was notified of the value when the isLoggedIn attribute was updated. The RP can then build a cookie that matches the User Agent to the Identitifier. Because AX unsolicited responses have to be verified with the OpenID Provider, forcing the RP to look up the Identifier using the value of the isLoggedIn attribute ensures that we are matching up to the correct Identifier, and removes a potential security hole. For RP-initiated log-out scenario, you can have the RP update the isLoggedIn attribute using Attribute Exchange. Since the change requires user approval, this will ensure a rogue RP cannot accidentally log the user out. Although browser extensions are great ideas, not all types of browsers can load extensions. For instance, a mobile phone or web tablet may not have the ability to install Verisign's Seatbelt. This is intended to be a way to have SSO-like functions without modifying the User Agent. Also, this is not technically a SSO implementation. We are not assuring all the RPs that this User Agent owns this OpenID. Only that we think it does. This means that each RP will have to perform its own (automated) OpenID login process when the User Agent visits the site. Since the cookie makes it easy to figure out which OpenID Identifier to use, the process becomes easy. Thanks, John On 2/20/08, Tatsuya KATSUHARA [EMAIL PROTECTED] wrote: Thanks! 1st: How to input OpenID implicitly. 2nd: How to SLO from RP/OP(How to notify to RP or OP). For 1st, you issue site-specific session cookie and notify the value of *isLoggedin* attribute requested on the last? explicit login from RP and UA'll get the authenticated session cookie via IMG tag. I think federationId should include OpenID/iname, or RP get anonymous user's authenticated session. Do you mention it? Incidentally, I think it's enough that browser extention feeds OpenID to the form automatically and start with openid.mode=immedidate. For 2nd, what you say is good way. In fact SAML2.0 do SingleLogOut negotiation. To add another word, it would be good to add RP-initiate logout scenario. As I said, browser extention acheve to logout automatically. But SingleLogOut timing should be right unlike SingleSingIn in the view of security. If any, please let me know good ideas. In all honesty, I feel this draft is a little tricky, but whether OpenID that is low-coupled takes SingleSingIn/LogOut into spec or not is very interesting issue. I would like to know how do subscribers think... -- =katsuhara http://xri.net/=katsuhara John Ehn wrote: I've posted a Draft 0 version to the OpenID Wiki. Please feel free to comment and modify as needed. http://wiki.openid.net/Federation_Extension Thanks, John On 2/19/08, John Ehn [EMAIL PROTECTED] wrote: Brett, No formal process. All RFC through the mailing list. Thanks, John On 2/19/08, Brett Carter [EMAIL PROTECTED] wrote: John Ehn wrote: Sounds good. I'm working on a draft. Once it's in a readable state, I'll post it for comments. Thanks! Is there a formal process for submitting a proposal yet? Or are we just going with RFC format for now? -Brett ___ 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
Re: Login Federation
Sounds good. I'm working on a draft. Once it's in a readable state, I'll post it for comments. Thanks! On 2/19/08, Brett Carter [EMAIL PROTECTED] wrote: This is close to what I was thinking, however why not simply pass the user's open id url to the external site, through some yet undefined parameter. This way, there's little chance for cache poisoning. Passing the open id url, the consumer site can just proceed with authentication normally, using any cached data it has already. Also, I think IMG tags are a better idea than IFRAMES, in another post. They're more compatible, for one. A point I didn't think of at first is that we have the converse issue of being able to log out of federated sites as well. -Brett On Feb 18, 2008, at 11:58 AM, John Ehn wrote: I think I've figured out the flow. It's seamless from the point of view of the user. It will require explicit support from the Idenity Provider (on top of AX), and the client website will need to have an AX update receiver that supports this as well. No special support is needed in the web browser. Turn on auto-logon on each site 1. Log into the relying party normally 2. Site begins OpenID authentication, sends AX request asking for the IsLoggedIn variable, and requests updates when the value changes. 3. User selects whether or not they want this to occur (automatically notify the site upon login) 4. From the user's point-of-view, login now occurs automatically at that site. Federated login 1. User logs in to OpenID Provider 2. IsLoggedIn variable is updated with a pseudo-random value 3. All sites subscribing to the IsLoggedIn variable are updated using AX. 4. OpenID Provider displays a page loaded with hidden iframes pointing to the same site URLs used for listening for AX updates. The IsLoggedIn variable is included as an argument. 5. Each site's iframe performs regular OpenID authentication using the identity info already cached by the AX update receiver. 6. As browser loads each iframe, it receives a standard login cookie from each site. 7. User can connect to each site and will be automatically logged in. Federated logout 1. User logs out of OpenID Provider 2. IsLoggedIn variable is updated with a value of false 3. All sites subscribing to the IsLoggedIn variable are updated using AX. 4. Each receiving site expires the user session. Does this sound feasible? On 2/18/08, John Ehn [EMAIL PROTECTED] wrote: This can be pretty easily done by piggy-backing on the Attribute Exchange extension. Have your OpenID Provider store a IsLoggedIn variable. When the value is updated, the OpenID Provider can update all the websites subscribing to the value. The tricky part is having the web browser be automatically identifiable from all of these supported sites. My first thought would be: * Store and send out the value in of the IsLoggedIn variable to all the websites * Give the browser multiple session cookies that are visible from each of the websites that the values was sent to, which contains a hash of the value plus the website URL. * When the website sees the cookie, it can take the cookie, generate and compare the hash. If the hashes match, automatically do an OpenID login * When the user logs out at the OpenID Provider, AX will update all subscribing websites, thereby logging the user out of all sites Although, I believe most web browsers won't let you store cookies that are visible from multiple sites. Perhaps someone more familiar with these mechanics and chip in? Maybe somehow detect the web browser's signature without involving any functionality in the browser itself? Thanks, John Ehn extremeswank.com On 2/18/08, Martin Paljak [EMAIL PROTECTED] wrote: On Feb 18, 2008, at 5:11 PM, McGovern, James F (HTSC, IT) wrote: Likewise, I would think that for automatic signon, it would be a good thing if the OpenID provider could tell the relying party how long to leave an otherwise idle session open before timing it out. Not sure if this would require an extension or not. expires_in from http://openid.net/specs/openid-authentication-2_0.html#anchor20 should do exactly this. m. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ 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
Re: Login Federation
Brett, No formal process. All RFC through the mailing list. Thanks, John On 2/19/08, Brett Carter [EMAIL PROTECTED] wrote: John Ehn wrote: Sounds good. I'm working on a draft. Once it's in a readable state, I'll post it for comments. Thanks! Is there a formal process for submitting a proposal yet? Or are we just going with RFC format for now? -Brett ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Login Federation
This can be pretty easily done by piggy-backing on the Attribute Exchange extension. Have your OpenID Provider store a IsLoggedIn variable. When the value is updated, the OpenID Provider can update all the websites subscribing to the value. The tricky part is having the web browser be automatically identifiable from all of these supported sites. My first thought would be: * Store and send out the value in of the IsLoggedIn variable to all the websites * Give the browser multiple session cookies that are visible from each of the websites that the values was sent to, which contains a hash of the value plus the website URL. * When the website sees the cookie, it can take the cookie, generate and compare the hash. If the hashes match, automatically do an OpenID login * When the user logs out at the OpenID Provider, AX will update all subscribing websites, thereby logging the user out of all sites Although, I believe most web browsers won't let you store cookies that are visible from multiple sites. Perhaps someone more familiar with these mechanics and chip in? Maybe somehow detect the web browser's signature without involving any functionality in the browser itself? Thanks, John Ehn extremeswank.com On 2/18/08, Martin Paljak [EMAIL PROTECTED] wrote: On Feb 18, 2008, at 5:11 PM, McGovern, James F (HTSC, IT) wrote: Likewise, I would think that for automatic signon, it would be a good thing if the OpenID provider could tell the relying party how long to leave an otherwise idle session open before timing it out. Not sure if this would require an extension or not. expires_in from http://openid.net/specs/openid-authentication-2_0.html#anchor20 should do exactly this. m. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ 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: Login Federation
I think I've figured out the flow. It's seamless from the point of view of the user. It will require explicit support from the Idenity Provider (on top of AX), and the client website will need to have an AX update receiver that supports this as well. No special support is needed in the web browser. Turn on auto-logon on each site 1. Log into the relying party normally 2. Site begins OpenID authentication, sends AX request asking for the IsLoggedIn variable, and requests updates when the value changes. 3. User selects whether or not they want this to occur (automatically notify the site upon login) 4. From the user's point-of-view, login now occurs automatically at that site. Federated login 1. User logs in to OpenID Provider 2. IsLoggedIn variable is updated with a pseudo-random value 3. All sites subscribing to the IsLoggedIn variable are updated using AX. 4. OpenID Provider displays a page loaded with hidden iframes pointing to the same site URLs used for listening for AX updates. The IsLoggedIn variable is included as an argument. 5. Each site's iframe performs regular OpenID authentication using the identity info already cached by the AX update receiver. 6. As browser loads each iframe, it receives a standard login cookie from each site. 7. User can connect to each site and will be automatically logged in. Federated logout 1. User logs out of OpenID Provider 2. IsLoggedIn variable is updated with a value of false 3. All sites subscribing to the IsLoggedIn variable are updated using AX. 4. Each receiving site expires the user session. Does this sound feasible? On 2/18/08, John Ehn [EMAIL PROTECTED] wrote: This can be pretty easily done by piggy-backing on the Attribute Exchange extension. Have your OpenID Provider store a IsLoggedIn variable. When the value is updated, the OpenID Provider can update all the websites subscribing to the value. The tricky part is having the web browser be automatically identifiable from all of these supported sites. My first thought would be: * Store and send out the value in of the IsLoggedIn variable to all the websites * Give the browser multiple session cookies that are visible from each of the websites that the values was sent to, which contains a hash of the value plus the website URL. * When the website sees the cookie, it can take the cookie, generate and compare the hash. If the hashes match, automatically do an OpenID login * When the user logs out at the OpenID Provider, AX will update all subscribing websites, thereby logging the user out of all sites Although, I believe most web browsers won't let you store cookies that are visible from multiple sites. Perhaps someone more familiar with these mechanics and chip in? Maybe somehow detect the web browser's signature without involving any functionality in the browser itself? Thanks, John Ehn extremeswank.com On 2/18/08, Martin Paljak [EMAIL PROTECTED] wrote: On Feb 18, 2008, at 5:11 PM, McGovern, James F (HTSC, IT) wrote: Likewise, I would think that for automatic signon, it would be a good thing if the OpenID provider could tell the relying party how long to leave an otherwise idle session open before timing it out. Not sure if this would require an extension or not. expires_in from http://openid.net/specs/openid-authentication-2_0.html#anchor20 should do exactly this. m. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ 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: Login Federation
Well, with some tweaking elsewhere. Hidden iframes are the smoothest way to do it. On 2/18/08, John Ehn [EMAIL PROTECTED] wrote: It was just an example. In theory, you could do it with an IMG or OBJECT tag. On 2/18/08, SignpostMarv Martin [EMAIL PROTECTED] wrote: John Ehn wrote: 5. Each site's iframe performs regular OpenID authentication using the identity info already cached by the AX update receiver. Doable without iframes ? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID 2.0 Section 9.2.1
I've been reviewing Draft 12, and noticed this section, which I think will cause problems for some systems. 9.2.1. Using the Realm for Return URL Verification OpenID providers SHOULD verify that the return_to URL specified in the request is an OpenID relying party endpoint. To verify a return_to URL, obtain the relying party endpoints for the realm by performing *discovery on the relying party (Discovering OpenID Relying Parties)*http://openid.net/specs/openid-authentication-2_0-12.html#rp_discovery. As always when performing discovery, the discovered URL is the URL of the last HTTP response, following redirects. If any redirects are followed when performing discovery on the realm, verification has failed. If discovery has successfuly completed, check to make sure that the return_to URL matches one of the relying party endpoints. A realm may contain a wildcard, and so may not be a valid URL. In that case, perform discovery on the URL obtained by substituting www for the wildcard in the realm. To match a return_to URL against a relying party endpoint, use the same rules as for matching the return_to URL against the realm, treating the relying party's endpoint URL as the realm. Relying party endpoint URLs MUST NOT contain a domain wildcard, and SHOULD be as specific as possible. *If verification is attempted and fails, the provider SHOULD NOT send a positive assertion to that return_to URL. * Providers MAY cache verified return_to URLs. I think it is a nice idea, however, it does not take into account situations where a Relying Party may not exist on the public Internet. For instance, let's say I have an intranet application. The following is true: - The application is located on a host in my office - My office is connected to the Internet via a NAT firewall (all internal IP addresses are not accessible from the Internet) - My application uses OpenID for authentication - A guest worker has been given permission to use my application with their OpenID provided by another company The following should happen: - The user will attempt to log in with their OpenID - My application will send a request to the OpenID Provider - The Provider will attempt to perform RP discovery - The RP discovery will fail - The OpenID Provider rejects the authentication request As you can see, for this use case, OpenID would no longer be usable. The first reaction will be well, this is a SHOULD, not a MUST. That's all well and good, however, this will cause any Intranet-based authentiation request to fail for any provider that decides to implement this SHOULD, which means we'll have minor frustration at least (you can switch to a provider that doesn't implement this SHOULD), or abandonment of OpenID entirely at worst. I believe we should allow the user to be warned about the discrepency, but all them to continue the authentication request if they are aware that RP is not accessible from the Internet. If I'm wrong, please let me know. Thank you, John Ehn extremeswank.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 2.0 Section 9.2.1
Okay. Can we re-word it then so it's more explicitly stated? I.E.: Attempt discovery. If discovery succeeds, ensure return_to URL is specified in the XRDS document. If not present, always return negative assertion. If discovery fails, assume return_to URL is valid and return assertion. Thanks! John Ehn extremeswank.com On 10/29/07, James Henstridge [EMAIL PROTECTED] wrote: On 29/10/2007, John Ehn [EMAIL PROTECTED] wrote: I've been reviewing Draft 12, and noticed this section, which I think will cause problems for some systems. 9.2.1. Using the Realm for Return URL Verification OpenID providers SHOULD verify that the return_to URL specified in the request is an OpenID relying party endpoint. To verify a return_to URL, obtain the relying party endpoints for the realm by performing discovery on the relying party (Discovering OpenID Relying Parties). As always when performing discovery, the discovered URL is the URL of the last HTTP response, following redirects. If any redirects are followed when performing discovery on the realm, verification has failed. If discovery has successfuly completed, check to make sure that the return_to URL matches one of the relying party endpoints. A realm may contain a wildcard, and so may not be a valid URL. In that case, perform discovery on the URL obtained by substituting www for the wildcard in the realm. To match a return_to URL against a relying party endpoint, use the same rules as for matching the return_to URL against the realm, treating the relying party's endpoint URL as the realm. Relying party endpoint URLs MUST NOT contain a domain wildcard, and SHOULD be as specific as possible. If verification is attempted and fails, the provider SHOULD NOT send a positive assertion to that return_to URL. Providers MAY cache verified return_to URLs. I think it is a nice idea, however, it does not take into account situations where a Relying Party may not exist on the public Internet. For instance, let's say I have an intranet application. The following is true: The application is located on a host in my office My office is connected to the Internet via a NAT firewall (all internal IP addresses are not accessible from the Internet) My application uses OpenID for authentication A guest worker has been given permission to use my application with their OpenID provided by another company The following should happen: The user will attempt to log in with their OpenID My application will send a request to the OpenID Provider The Provider will attempt to perform RP discovery The RP discovery will fail The OpenID Provider rejects the authentication request As you can see, for this use case, OpenID would no longer be usable. From my reading of the spec, the OP only tries to verify the return_to value if RP discovery succeeds. If RP discovery fails, then return_to verification is not attempted. In the case of an intranet RP (or any other RP that hasn't implemented discovery), any return_to URL that matches the realm should be acceptable. The case where the OP SHOULD NOT return a positive assertion is if: 1. the OP attempts RP discovery 2. RP discovery succeeds 3. the return_to URL is not in the list of discovered RP endpoints James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: An OAuth OpenID Extension
Joseph, Any help you could provide to flesh out (or heavily modify) these specs would be most appreciated. Thanks, John Ehn extremeswank.com On 10/22/07, Joseph Holsten [EMAIL PROTECTED] wrote: Wow, these are neat. Thanks for the links david, and especially the work john! OK, so the Inline Auth use case seems like a straightforward case for OAuth: resource url = identifier, user auth url = delegate. Successfully accessing the resource after negotiation would imply that the user still trusts the RP. Seems like low hanging fruit. Also, gets the benefit of single sign off! I'm a little unsure about the best way for the Trusted Auth use case. This seems quite good, but a diagram of an oauth solution to the problem was on the mailing list not long ago. Same as the official diagram, but with a third column showing interactions between the Consumer Directs User to Service Provider and Service Provider Directs User to Consumer steps. I looked for half an hour, found nothing, but I'm not crazy really! Anyway, it would be nice to compare perspectives first. But if I remember correctly, the oauth proposal only allowed the Service Provider/Destination Consumer to revoke resource access, while openid trusted auth gives that right to the OP. Greater overhead versus greater user control. So who's interested in fleshing out these recommendations into specs? http:/ joseph holsten .com On 02007:10:22, at 3:54CDT, David Recordon wrote: Hey all, I know John did some work in September (http://extremeswank.com/ openid_trusted_auth.html and http://extremeswank.com/ openid_inline_auth.html). Both solve extremely important use-cases and are becoming increasingly discussed especially with the advent of OAuth. I'd really like to see how we can work to write an extension to OpenID Authentication where the OpenID Provider is also the one handling OAuth credentials. This would be useful in the inline authentication use case as well as if we move to a deployment scenario where the OAuth Provider is checking with the user's OpenID Provider to verify OAuth signatures. Overtime I also think moving OpenID to the OAuth signature mechanism would be beneficial, but I think that is a longer conversation. --David ___ 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
OpenID Inline Authentication Extension 1.0 Draft 1
The Inline Authentication Extension attempts to solve the problem of legacy and interactive applications (Telnet/SSH) that are unable to launch a client Web Browser to perform an authentication request. http://extremeswank.com/openid_inline_auth.html This is done through the use of verification keys, which are provided either as needed by the OpenID Provider, or provided on a rotating basis from a hardware crypto device, or a key generating token (SecurID). As always, your comments are appreciated! Thank you, John Ehn ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Inline Authentication Extension 1.0 Draft 1
Hans, Yes, the Client App is expected to implement all the important parts of an OpenID 2.0 Relying Party. This means it will support XRI, Yadis, and HTML discovery. It's unlikely systems will have clashing namespaces, but is possible (most corporate user accounts don't begin with =, @, +, etc, and most don't use a format similar to URLs). For a PAM implementation, the system would likely give priority to all other authentication types, and fall back to OpenID if there are no matches. Or, the implementor may wish to prompt the user for the authentication type, or provide instructions to add a special prefix to the account name. As for the wording in step 4, oops. Thanks for catching that. It should be The user is prompted for their verification key, which is typed in and submitted. I have never personally done a PAM module, so I'm not a good fit. I think it would work very well though. Know anyone who might want to give it a try? Thanks, John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Trusted Authentication Extension
On 8/31/07, James Henstridge [EMAIL PROTECTED] wrote: You still want the user involved in the granting of an authentication token though, right? Trying to replace the UA in the authentication workflow is quite a big change, and limits what the OP can do. Yes, granting the secret must be done using the traditional User Agent, as the user must be logged in using their normal credentials in order for the OP to deliver the secret to the requesting RP. Considering it's an Extension, this isn't really any sort of change that limits what the OP can do. It simply codes a standard credential format that is only used for when a site wishes to log into another site using a specific OpenID. With your proposal, the user's OP needs to implement an extension. This brings up a few questions: 1. Should the data provider only let users register if their OP implements the extension? What is the benefit to the data provider in enforcing such an extension? Trusted Authentication doesn't require the destination site (the DP) to implement any changes at all. One would hope that the DP is offering some valuable service other than just providing data to client sites. As for the client site, yes, functionality will be lost if the OP doesn't support the extension that would allow them to log in to another site. If the extension becomes popular, it would be in the best interest of the OP to implement the extension if they wanted to keep users from switching to a different provider that does support the extension. 2. If only some users' OPs implement the extension, can the data consumer rely on the protocol at all? Why not? They would be able to support this, and if the OP doesn't support the extension, they can continue using those very insecure API key implementations that are being used today. Or, they can even suggest that the user switch to a supporting provider. In contrast, both the data provider and consumer have an incentive to implement an extension for auth token transfer, so a spec that only requires modifications to those parties seems easier to roll out. What do you think? Well, as above, no changes are needed at the DP. I think it would be much easier to simply modify the hand-full of OPs and the Client RPs that want to support the spec, which is expected with any OpenID extension. [snip] to log on to the destination site to invalidate the token. What if the user has 50 of these API connections set up? That's 50 sites to visit in order to manage these tokens. I guess that is a concern. But how often do you expect the data provider to check the user's OP to see if the token is still valid? If it doesn't check often, then revoking the token at the OP level might take a while to take effect. Well, it really is up to the DP to determine how long it wants its sessions open, just with any other website. For instance, banks will automatically expire the session if there is no activity for 15 minutes. In this case, the DP will simply force the Client RP to authenticate again with the OP. As stated in the spec, it's not my intention to mandate how user data (and the data session) is managed between the client RP and the DP. Your feedback is always welcome. Thanks, John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Trusted Authentication Extension
Well, I've slept on it. I think we have a difference in philosophy. The other Extesions - AX, Simple Registration, etc. - follow the same data flow methodology: RP - UA - OP RP - UA - OP I believe I'm sticking to the same principles in my spec. We are doing the very same thing when we collect the authentication key (see above). We are even doing the very same thing when we have the sites authenticate with each other. It's just we have a non-human operating the User Agent. In this case, the RP is the destination site, the UA is the client site: RP - UA - OP RP - UA - OP I think this fits well with what people expect. I also have no problem with having OPs incrementally improve their systems to make them compatible with new extensions. Since there will (eventually) be far more RPs out there than OPs, I think it's reasonable for them to support the bulk of the extension implementation. In this case, however, there really isn't all that much to implement. The following code changes will need to happen at the site that wants access to information at another site (the CC): * The form where the user submits their OpenID to grant permission to another site * Logic that builds a simple OpenID login request with the Trusted Authentication data included, and a redirect to the OP * A branch to the id_res checker that parses the OP response and stores the shared secret * An automated script that performs OpenID authentication to the DC and retreives data The OP needs to implement the following: * When receiving a check_id request with Trusted Authentication arguments, send an X-OPENID-TrustedAuthentication HTTP header in the response, and be able to accept a SHA-256 hash as a response - This is not a big deal, and isn't any form of deviation, because this is the gray area in the spec where the UA is supposed to be verified that it's already logged in, or is prompted for credentials * Add a logic branch that generates a shared secret when requested, stores it, and sends it in the authentication response * Some form of user interface to manage the stored secrets - very easy All but one of these steps would be needed to implement ANY OpenID extension out there. And the only change that is out of spec is accepting an SHA-256 hash as an authentication key - which is trivial to implement at an OP. Conservatively, (with distractions) I think an OP can implement the data passing in less than a couple of hours, and the user interface in a couple of days. Although your implementation is sound, and I like a lot of the ideas, they shift a lot of the responsibility to the party receiving the authentication request. I'm not sure I like the idea of having the burden of implementing both an API and a special pseudo-OP. This also removes the power of having a single Identity management interface at the OP, meaning the user will have to log on to the destination site to invalidate the token. What if the user has 50 of these API connections set up? That's 50 sites to visit in order to manage these tokens. Like I said, nothing technically wrong with the idea (it's novel), but it just doesn't fit with me. Thank you! John Ehn On 8/30/07, James Henstridge [EMAIL PROTECTED] wrote: On 30/08/2007, John Ehn [EMAIL PROTECTED] wrote: James, Sorry, but I'm having problems following the flow. It seems like an interesting idea, though. Can you provide with a little more information on how these components would interact? Okay. The basic idea was that instead of creating a special protocol for two OpenID relying parties to communicate with each other was for the web services data provider to act as an OpenID provider. So, lets assume that the data consumer wants an auth token for the user identified by http://user.identifier.url. With normal OpenID authentication, you'd perform discovery to find the user's OpenID provider. To request an auth token though we need to talk to the data provider, so instead we skip discovery and perform an authentication request to the data provider's endpoint. The parameters might look something like this: * openid.mode = checkid_setup * openid.claimed_id = http://user.identifier.url * openid.identity = http://user.identifier.url * openid.return_to = http://data.consumer/. http://data.consumer/.. * openid.ns.auth = ... * (additional parameters related to the auth token request) The data provider would then decide whether to grant the auth token (possibly by performing OpenID authentication against http://user.identifier.url, and/or asking the user), then send a response back like: * openid.mode = id_res * openid.claimed_id = http://user.identifier.url * openid.identity = http://user.identifier.url * openid.return_to = http://data.consumer/. http://data.consumer/.. * openid.ns.auth = ... * openid.auth.token = ... * openid.auth.secret = ... The data consumer knows that the request came from the data provider due to the signature
Re: OpenID Trusted Authentication Extension
James, Sorry, but I'm having problems following the flow. It seems like an interesting idea, though. Can you provide with a little more information on how these components would interact? I was really trying to keep everything dumb and simple. The concept I was going for was piggy-back on OpenID, but include a way to programmatically log on to the OpenID Provider. The problem I saw with OpenID was that there are about a million different ways to authenticate with an OpenID Provider, from HTML forms to digital certificates. Most require the User Agent to be a web browser. However, there is no standard way to just pass a credential that can prove that you are who you say you are. Trusted Connection Request: User Agent gives OpenID to Client Consumer Client Consumer - User Agent - OpenID Provider Trusted Connection Response (with key): Client Consumer - User Agent - OpenID Provider Trusted Logon: Client Consumer gives OpenID Identity to Destination Consumer Destination Consumer - Client Consumer - OpenID Provider Destination Consumer - Client Consumer - OpenID Provider I was trying to solve the problem by coming up with an automatable (if that's a word) way to authenticate with an OpenID Provider. If we have that, there's no need to pass around a special token, because we can just use standard OpenID authentication if we want to log on to another system. So, I proposed just having the Consumer get a key from the OpenID Provider that it can use to automatically authenticate with the Provider in the future. The key is passed through the user when it's granted, because you need the user to approve the whole thing anyway. I don't expect this extension to fix all problems. It's only intended to solve a specific use case (website to website info sharing). I am working on two additional extensions which will solve the other problems I see: * Inline Authentication - Provide support for legacy and real-time interactive systems that can't launch a web browser, and are protecting their own data (Telnet, etc). This will involve manually-typed verification keys. * Desktop Authentication - Provide for desktop applications authenticating with and accessing data behind third-party systems (RSS readers, chat, etc). I appreciate any feedback you can give me. Thank you! John Ehn On 8/30/07, James Henstridge [EMAIL PROTECTED] wrote: On 26/08/07, John Ehn [EMAIL PROTECTED] wrote: I have created a draft of a new specification that I think will help to fill a gap in OpenID functionality. What appears to be a newer productivity feature of many websites is the ability to import and utilize information from other sites. For instance, Basecamp provides an API that allows other systems to access user data. This is a great feature, but it currently cannot be done with OpenID, due to the dependence on end-user interaction during the authentication process. The Trusted Authentication Extension provides for the ability for an OpenID Consumer to log in to another OpenID Consumer without user interaction. The end user will be able to create a trusted connection between two OpenID enabled sites, which will allow a client site to access a destination site using the end user's Identity. Please provide your comments and feedback, as they are most appreciated. http://extremeswank.com/openid_trusted_auth.html I think things would be a bit clearer if you made the data provider into a form of OpenID Provider. I think it helps to first consider the case where the data provider is not an OpenID Relying party but instead has its own user account database. If the site acted as an OpenID provider, it would be pretty simple to use an extension to negotiate an auth token to acess data for the user. Simply start an OpenID authentication request, including some field stating that you want access to data. The provider would then include an authentication token in the response that could be used to access the web services. Now lets consider the case where the data provider identifies users by an OpenID. What would happen if the data provider continued to implement an OP, and the data consumer started an OpenID authentication request with it using the user's data provider. This would let us use the same sort of OpenID extension to negotiate the auth token. The data provider could even turn around and perform its own authentication request to verify that the user is who they say they are, since it received the identity URL from the data consumer. So the full workflow might go like this: DC: Data Consumer DP: Data Provider OP: User's OpenID Provider 1. DC sends checkid_setup request to DP for user's identity URL, with an extension asking to negotiate an auth token. 2. DP initiates OpenID authentication for user's identity URL 3. OP verifies user's identity and sends idres reply to DP. 4. DP sends idres reply to DC, including the auth token
Re: OpenID Trusted Authentication Extension
Ahhh, I see what you're going for. It's a very interesting idea. On 8/30/07, James Henstridge [EMAIL PROTECTED] wrote: On 30/08/2007, John Ehn [EMAIL PROTECTED] wrote: James, Sorry, but I'm having problems following the flow. It seems like an interesting idea, though. Can you provide with a little more information on how these components would interact? Okay. The basic idea was that instead of creating a special protocol for two OpenID relying parties to communicate with each other was for the web services data provider to act as an OpenID provider. So, lets assume that the data consumer wants an auth token for the user identified by http://user.identifier.url. With normal OpenID authentication, you'd perform discovery to find the user's OpenID provider. To request an auth token though we need to talk to the data provider, so instead we skip discovery and perform an authentication request to the data provider's endpoint. The parameters might look something like this: * openid.mode = checkid_setup * openid.claimed_id = http://user.identifier.url * openid.identity = http://user.identifier.url * openid.return_to = http://data.consumer/... * openid.ns.auth = ... * (additional parameters related to the auth token request) The data provider would then decide whether to grant the auth token (possibly by performing OpenID authentication against http://user.identifier.url, and/or asking the user), then send a response back like: * openid.mode = id_res * openid.claimed_id = http://user.identifier.url * openid.identity = http://user.identifier.url * openid.return_to = http://data.consumer/... * openid.ns.auth = ... * openid.auth.token = ... * openid.auth.secret = ... The data consumer knows that the request came from the data provider due to the signature on the OpenID response. The data provider knows which user to create the token for because it was present in the OpenID request. The data provider can verify that the web browser user is that user because control gets transferred to the data provider during the authentication process. This all assumes that the data consumer has already authenticated the user, so knows which identity URL to request a token for from the data provider. I was really trying to keep everything dumb and simple. The concept I was going for was piggy-back on OpenID, but include a way to programmatically log on to the OpenID Provider. The problem I saw with OpenID was that there are about a million different ways to authenticate with an OpenID Provider, from HTML forms to digital certificates. Most require the User Agent to be a web browser. However, there is no standard way to just pass a credential that can prove that you are who you say you are. Well, OpenID authentication requests are designed to let the OP perform whatever checking they want before sending a response. So by making the data provider act as an OP, it has the same freedom (including the freedom to issue its own OpenID authentication request to the user's actual OP). I was trying to solve the problem by coming up with an automatable (if that's a word) way to authenticate with an OpenID Provider. If we have that, there's no need to pass around a special token, because we can just use standard OpenID authentication if we want to log on to another system. So, I proposed just having the Consumer get a key from the OpenID Provider that it can use to automatically authenticate with the Provider in the future. The key is passed through the user when it's granted, because you need the user to approve the whole thing anyway. I think that this makes things more complicated than need be. If you want an auth token from the data provider it seems better to ask the data provider for the key directly, giving it the chance to authenticate the user before responding. This also has the benefit that it does not require any special features from the user's OP -- the extension is purely concerned with the interaction between data consumer and provider. I don't expect this extension to fix all problems. It's only intended to solve a specific use case (website to website info sharing). I am working on two additional extensions which will solve the other problems I see: Sure. I doubt my suggested workflow would help with those use cases either (at least without some additional components). James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Trusted Authentication Extension
Chris, I want to start off by saying how horribly inappropriate it is to use the OpenID specifications mailing list to peddle an authentication standard that has absolutely nothing to do with OpenID. I find it interesting that so many of the OAuth community have taken time out of their busy schedules to tell me to back off on my extension to OpenID. Every single response to my specification has mentioned OAuth, and all with a very defensive tone. Only one or two responses have had any constructive criticism about the actual content of the specification. To MY defense, I didn't even know about OAuth until I was reminded of it in response to my specification. I have attempted to review the spec, but am unable to locate it anywhere, even though I joined the Google Group, as requested. Due to the very public negative response from the OAuth folks, I am tempted to remove myself from the group as a result. As for consensus, I simply don't care. This was an exercise to allow OpenID to fill the needs of a specific use case. I believe it is extremely simple to implement, and is reasonably secure. If the OpenID folks decide to adopt it, I will be very happy. If not, I will still be happy. I am passionate about OpenID. I feel that if I want it succeed, I should work to extend it, and I should have the freedom to do so. Thank you, John Ehn On 8/29/07, Chris Messina [EMAIL PROTECTED] wrote: Hi John, Looks like there's some consensus around OAuth... ;) I helped to get OAuth off the ground to solve the very problem that you're looking to solve -- in our case, enabling Ma.gnolia OpenID users to use Dashboard Widgets and Twitter API users to authenticate their apps, eventually using OpenID. While I appreciate your work on an OpenID-specific extension, I think there's some legitimacy in looking at a solution that works generally regardless of the authentication mechanism. By decoupling OpenID and OAuth, the goal was to make it easier to adopt OAuth first and then lead into adopting OpenID. In the case of your spec, which seems like a good piece of work, there'd be no sense in supporting the extension without supporting OpenID and as such, has limited benefit in the wild for implementors. With OAuth, if we're able to get folks like AOL, Google, Yahoo and others to support it, the amount of effort necessary to support all of them becomes the same amount of work to support one. Anyway, I'm glad to see you on the OAuth list. Feel free to poke around; we're looking to put out a 0.9 Draft and have it implemented over the course of September in libraries and then release finally a 1.0 Oct 1. Cheers, Chris On 8/27/07, David Fuelling [EMAIL PROTECTED] wrote: John, Have a look at OAuth (http://groups.google.com/group/oauth). I think it's currently a private google group, but it seems like you've given a lot of thought to this type of thing, so I'm sure the group owners would welcome your input. There's a lot of activity going on over there. David On 8/26/07, John Ehn [EMAIL PROTECTED] wrote: I have created a draft of a new specification that I think will help to fill a gap in OpenID functionality. What appears to be a newer productivity feature of many websites is the ability to import and utilize information from other sites. For instance, Basecamp provides an API that allows other systems to access user data. This is a great feature, but it currently cannot be done with OpenID, due to the dependence on end-user interaction during the authentication process. The Trusted Authentication Extension provides for the ability for an OpenID Consumer to log in to another OpenID Consumer without user interaction. The end user will be able to create a trusted connection between two OpenID enabled sites, which will allow a client site to access a destination site using the end user's Identity. Please provide your comments and feedback, as they are most appreciated. http://extremeswank.com/openid_trusted_auth.html Thank you, John Ehn [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Chris Messina Citizen Provocateur Open Source Advocate-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID Trusted Authentication Extension
I have created a draft of a new specification that I think will help to fill a gap in OpenID functionality. What appears to be a newer productivity feature of many websites is the ability to import and utilize information from other sites. For instance, Basecamp provides an API that allows other systems to access user data. This is a great feature, but it currently cannot be done with OpenID, due to the dependence on end-user interaction during the authentication process. The Trusted Authentication Extension provides for the ability for an OpenID Consumer to log in to another OpenID Consumer without user interaction. The end user will be able to create a trusted connection between two OpenID enabled sites, which will allow a client site to access a destination site using the end user's Identity. Please provide your comments and feedback, as they are most appreciated. http://extremeswank.com/openid_trusted_auth.html Thank you, John Ehn [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
