Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Dirk Balfanz wrote: On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: In Section 10, and perhaps also in Section 12, the spec should mention that because the hybrid protocol does not have a request token secret, and because the user is never required to manually type in the request token (unlike in OAuth), the hybrid Request Token probably should be longer and harder to guess than the standard OAuth Request Token. At least for our implementation, I'm thinking that the hybrid RT == OAuth's RT+RTSecret. But you need to have the consumer secret to exchange it, no? What if it were just a incrementing integer? What would the attack be? Yes, the attacker would still need the Consumer Secret, however in vanilla OAuth, the attacker would need the Consumer Key, Consumer Secret, Request Token, and Request Token Secret. Because there's one less secret, the Access Token could be more vulnerable to hijacking from brute force attacks where RTs are just randomly scanned. In our case, Yahoo issues relatively short Request Tokens from a limited character set to make them easy to type. We compensate for the short RTs by pairing them with long RTSecrets. If we were to implement the hybrid protocol, our hybrid RTs would be much longer than the regular OAuth RTs. We also believe that developers may inadvertently leak their Consumer Secrets. We're seeing lots of questions from developers who are trying to use OAuth from within Javascript and Flash, which implies that they're going to be leaking the secret to the browser. Developers may also reuse their website's Consumer Key into a downloadable client application. Allen ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Interesting point, and probably worth adding to a security portion of the spec. I would say though, that is bad security hygiene to share the same consumer key between your web and desktop apps. Since we can't vouch for consumer keys stored in desktop apps anyway, I would volunteer that the most sensible thing is to have empty consumer keys in that case (and warn users that we can't vouch for the origin of the request). On Tue, Dec 2, 2008 at 4:37 PM, Allen Tom [EMAIL PROTECTED] wrote: Dirk Balfanz wrote: On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom [EMAIL PROTECTED] wrote: In Section 10, and perhaps also in Section 12, the spec should mention that because the hybrid protocol does not have a request token secret, and because the user is never required to manually type in the request token (unlike in OAuth), the hybrid Request Token probably should be longer and harder to guess than the standard OAuth Request Token. At least for our implementation, I'm thinking that the hybrid RT == OAuth's RT+RTSecret. But you need to have the consumer secret to exchange it, no? What if it were just a incrementing integer? What would the attack be? Yes, the attacker would still need the Consumer Secret, however in vanilla OAuth, the attacker would need the Consumer Key, Consumer Secret, Request Token, and Request Token Secret. Because there's one less secret, the Access Token could be more vulnerable to hijacking from brute force attacks where RTs are just randomly scanned. In our case, Yahoo issues relatively short Request Tokens from a limited character set to make them easy to type. We compensate for the short RTs by pairing them with long RTSecrets. If we were to implement the hybrid protocol, our hybrid RTs would be much longer than the regular OAuth RTs. We also believe that developers may inadvertently leak their Consumer Secrets. We're seeing lots of questions from developers who are trying to use OAuth from within Javascript and Flash, which implies that they're going to be leaking the secret to the browser. Developers may also reuse their website's Consumer Key into a downloadable client application. Allen -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
It's definitely bad hygiene for developers to leak their secrets to the browser, or to reuse their website's CK for a downloadable client application, and we're doing all that we can to encourage good hygiene. For the time being, we prefer to require CKs for client applications (even if they can't be verified) mostly to make it easy for us to pull the plug on specific applications if they are discovered to be severely buggy or dangerous. We'd also like to require pre-registration of CKs so that we know who to contact about a particular app if we have any questions. Allen Breno de Medeiros wrote: Interesting point, and probably worth adding to a security portion of the spec. I would say though, that is bad security hygiene to share the same consumer key between your web and desktop apps. Since we can't vouch for consumer keys stored in desktop apps anyway, I would volunteer that the most sensible thing is to have empty consumer keys in that case (and warn users that we can't vouch for the origin of the request). On Tue, Dec 2, 2008 at 4:37 PM, Allen Tom [EMAIL PROTECTED] wrote: Dirk Balfanz wrote: On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom [EMAIL PROTECTED] wrote: In Section 10, and perhaps also in Section 12, the spec should mention that because the hybrid protocol does not have a request token secret, and because the user is never required to manually type in the request token (unlike in OAuth), the hybrid Request Token probably should be longer and harder to guess than the standard OAuth Request Token. At least for our implementation, I'm thinking that the hybrid RT == OAuth's RT+RTSecret. But you need to have the consumer secret to exchange it, no? What if it were just a incrementing integer? What would the attack be? Yes, the attacker would still need the Consumer Secret, however in vanilla OAuth, the attacker would need the Consumer Key, Consumer Secret, Request Token, and Request Token Secret. Because there's one less secret, the Access Token could be more vulnerable to hijacking from brute force attacks where RTs are just randomly scanned. In our case, Yahoo issues relatively short Request Tokens from a limited character set to make them easy to type. We compensate for the short RTs by pairing them with long RTSecrets. If we were to implement the hybrid protocol, our hybrid RTs would be much longer than the regular OAuth RTs. We also believe that developers may inadvertently leak their Consumer Secrets. We're seeing lots of questions from developers who are trying to use OAuth from within Javascript and Flash, which implies that they're going to be leaking the secret to the browser. Developers may also reuse their website's Consumer Key into a downloadable client application. Allen ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Tue, Dec 2, 2008 at 4:58 PM, Allen Tom [EMAIL PROTECTED] wrote: It's definitely bad hygiene for developers to leak their secrets to the browser, or to reuse their website's CK for a downloadable client application, and we're doing all that we can to encourage good hygiene. For the time being, we prefer to require CKs for client applications (even if they can't be verified) mostly to make it easy for us to pull the plug on specific applications if they are discovered to be severely buggy or dangerous. We'd also like to require pre-registration of CKs so that we know who to contact about a particular app if we have any questions. Sounds reasonable. Allen Breno de Medeiros wrote: Interesting point, and probably worth adding to a security portion of the spec. I would say though, that is bad security hygiene to share the same consumer key between your web and desktop apps. Since we can't vouch for consumer keys stored in desktop apps anyway, I would volunteer that the most sensible thing is to have empty consumer keys in that case (and warn users that we can't vouch for the origin of the request). On Tue, Dec 2, 2008 at 4:37 PM, Allen Tom [EMAIL PROTECTED] wrote: Dirk Balfanz wrote: On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom [EMAIL PROTECTED] wrote: In Section 10, and perhaps also in Section 12, the spec should mention that because the hybrid protocol does not have a request token secret, and because the user is never required to manually type in the request token (unlike in OAuth), the hybrid Request Token probably should be longer and harder to guess than the standard OAuth Request Token. At least for our implementation, I'm thinking that the hybrid RT == OAuth's RT+RTSecret. But you need to have the consumer secret to exchange it, no? What if it were just a incrementing integer? What would the attack be? Yes, the attacker would still need the Consumer Secret, however in vanilla OAuth, the attacker would need the Consumer Key, Consumer Secret, Request Token, and Request Token Secret. Because there's one less secret, the Access Token could be more vulnerable to hijacking from brute force attacks where RTs are just randomly scanned. In our case, Yahoo issues relatively short Request Tokens from a limited character set to make them easy to type. We compensate for the short RTs by pairing them with long RTSecrets. If we were to implement the hybrid protocol, our hybrid RTs would be much longer than the regular OAuth RTs. We also believe that developers may inadvertently leak their Consumer Secrets. We're seeing lots of questions from developers who are trying to use OAuth from within Javascript and Flash, which implies that they're going to be leaking the secret to the browser. Developers may also reuse their website's Consumer Key into a downloadable client application. Allen -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Allen Tom wrote: For the time being, we prefer to require CKs for client applications (even if they can't be verified) mostly to make it easy for us to pull the plug on specific applications if they are discovered to be severely buggy or dangerous. We'd also like to require pre-registration of CKs so that we know who to contact about a particular app if we have any questions. If I make a dangerous app using the consumer key from a popular application, would you black list that key and inconvenience all of its users? (I doubt it.) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom [EMAIL PROTECTED] wrote: Some more feedback: The first sentence in the Abstract should say describes instead of describe. Done. The phrase OpenID OAuth Extension is not consistently capitalized in the spec. For instance, it's capitalized in the first sentence in section 3, but extension is lowercase in section 4. Sections 5 and 8 call it the OAuth extension, rather than the OpenID OAuth Extension. Done. The second word in Section 7, Requesting should be all lowercase. Done. In Section 7, the phrase this extension can be used to request that the end user authorize an OAuth token should probably be clarified to say that the user is authorizing an OAuth Access token. Done. This assumes that authorizing an access token is the same as approving a request token that can be exchanged for an access token. In the last sentence of Section 8, the phrase SHOULD not should be in all caps, SHOULD NOT. Done. I recommend that the phrase Combined Consumer be used instead of simply Consumer everywhere in the spec. The third paragraph in section 9, and the description for OAuth token secret in Section 10 still say Consumer. Done. In Section 10, is the Access Token endpoint discoverable? I guess that's out of scope for this spec. Yes it should be discoverable, but we don't know yet how that will work. According to Eran, The Right Way to do this is provide meta-data for the OpenID endpoint, and have that point to the access token endpoint. So you would serve something like this as the meta-data for your actual OpenID endpoint: XRD Typehttp://specs.openid.net/auth/2.0/server/Type Typehttp://specs.openid.net/extensions/oauth/1.0/Type Service Typehttp://oauth.net/core/1.0/endpoint/access/Type URIhttp://url-of-the-access-token-endpoint//URI /Service XRD But this kind of stuff has yet to gel in the various committees looking at discovery. As far as I know, in current versions of XRD(S), you can't have Type elements underneath XRD elements. Once that's all sorted out, we should probably include it in the spec. Although it might be that it falls out automatically out of XRD in general and OAuth discovery in particular, i.e. we would basically just have to remind the reader of how to put those other pieces together to make the access token endpoint discoverable. In Section 10, and perhaps also in Section 12, the spec should mention that because the hybrid protocol does not have a request token secret, and because the user is never required to manually type in the request token (unlike in OAuth), the hybrid Request Token probably should be longer and harder to guess than the standard OAuth Request Token. At least for our implementation, I'm thinking that the hybrid RT == OAuth's RT+RTSecret. But you need to have the consumer secret to exchange it, no? What if it were just a incrementing integer? What would the attack be? I think the spec is getting pretty close. Thanks again, Allen - this is really helpful! Dirk. thanks Allen Dirk Balfanz wrote: Otherwise, the spec is looking pretty good! Great! We're officially calling it Draft 1 now :-) (the previous version was Draft 0). ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Some more feedback: The first sentence in the Abstract should say describes instead of describe. The phrase OpenID OAuth Extension is not consistently capitalized in the spec. For instance, it's capitalized in the first sentence in section 3, but extension is lowercase in section 4. Sections 5 and 8 call it the OAuth extension, rather than the OpenID OAuth Extension. The second word in Section 7, Requesting should be all lowercase. In Section 7, the phrase this extension can be used to request that the end user authorize an OAuth token should probably be clarified to say that the user is authorizing an OAuth Access token. In the last sentence of Section 8, the phrase SHOULD not should be in all caps, SHOULD NOT. I recommend that the phrase Combined Consumer be used instead of simply Consumer everywhere in the spec. The third paragraph in section 9, and the description for OAuth token secret in Section 10 still say Consumer. In Section 10, is the Access Token endpoint discoverable? I guess that's out of scope for this spec. In Section 10, and perhaps also in Section 12, the spec should mention that because the hybrid protocol does not have a request token secret, and because the user is never required to manually type in the request token (unlike in OAuth), the hybrid Request Token probably should be longer and harder to guess than the standard OAuth Request Token. At least for our implementation, I'm thinking that the hybrid RT == OAuth's RT+RTSecret. I think the spec is getting pretty close. thanks Allen Dirk Balfanz wrote: Otherwise, the spec is looking pretty good! Great! We're officially calling it Draft 1 now :-) (the previous version was Draft 0). ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Fri, Nov 21, 2008 at 4:11 PM, Allen Tom [EMAIL PROTECTED] wrote: A couple minor edits are needed to Section 12: Security Considerations. I assume that the response_token in Section 12 is the same as the request_token in Section 9. The terminology needs to be consistent. Is shoudl be changed to are in the phrase The following security principles is reflected in this design Done. Thanks for spotting these! Dirk. Otherwise, the spec is looking pretty good! Allen Dirk Balfanz wrote: Ok, new version is up. I took out the sentence that recommended to send a cancel. I also added a section on discovery (just copied whatever the AX extension says about that). ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
I'm not sure. While I've seen OAuth interop really being hampered by that extension not being implemented in many libraries, and I generally think it's a good thing to report errors as detailed as possible, this does seem a very Un-OpenID-thing to do. They specify only two error conditions: the user didn't want to log in and we can't log in the user without showing them a UI (and this includes the AX extension). Of course, a lot more can go wrong, and there doesn't seem to be a notion in OpenID that this would be communicated, through a browser redirect, to the consumer. Perhaps the unspoken rule is that the redirect just doesn't happen when something goes wrong? In that case, the OP would just show a descriptive error page to the user? I don't know... Dirk. On Fri, Nov 21, 2008 at 4:04 PM, Allen Tom [EMAIL PROTECTED] wrote: How about if the openid.oauth.scope response parameter defined in Section 9 be changed to be a more generic OAuth status indicator? It can be used to indicate which scopes were authorized in the success case, or it can be used as status/problem indicator if there was an error. Perhaps the allowed values can be the same as the values defined in the ProblemReporting extension. http://oauth.pbwiki.com/ProblemReporting Allen Dirk Balfanz wrote: On Wed, Nov 19, 2008 at 2:31 PM, Allen Tom [EMAIL PROTECTED] wrote: Since the new hybrid draft spec doesn't affect the OpenID association method, this is moot. However, the spec should mention what SPs should do if the CK is invalid (or doesn't match the realm) in the OpenID authentication request. Presumably, the SP should continue servicing the OpenID portion of the request, however, the response should indicate why the OAuth portion of the request failed. How about, to mimic what happens with association handles, we can return in the response an openid.oauth.invalid_consumer parameter instead of openid.oauth.consumer? It would mean that either the CK was just wrong or that it didn't match the realm. Although at this point it starts to get pretty complicated. Does this error condition really need to be communicated back to the RP? For development etc., it might be enough to just show an error page to the user explaining what happened. Dirk. Allen Dirk Balfanz wrote: I'd recommend an error consistent with Section 8.2.4 in the OpenID 2.0 spec, with a new error_code value indicating that the either the CK or the realm was invalid. There may actually need to be 2 errors, one to indicate that the CK is invalid, and another to indicate that the CK is not valid for the realm. http://openid.net/specs/openid-authentication-2_0.html#anchor20 But Section 8.2 is about the association response. In the auth response, we currently only have cancel or setup_needed. If we invent another error condition there, we're no longer a pure extension. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
BTW, I reorganized the SVN layout on the server a little bit. The old URL now points to an old version of the draft. The latest version will from now on always be here: http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html Dirk. On Fri, Nov 21, 2008 at 4:11 PM, Allen Tom [EMAIL PROTECTED] wrote: A couple minor edits are needed to Section 12: Security Considerations. I assume that the response_token in Section 12 is the same as the request_token in Section 9. The terminology needs to be consistent. Is shoudl be changed to are in the phrase The following security principles is reflected in this design Otherwise, the spec is looking pretty good! Allen Dirk Balfanz wrote: Ok, new version is up. I took out the sentence that recommended to send a cancel. I also added a section on discovery (just copied whatever the AX extension says about that). ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
How about if the openid.oauth.scope response parameter defined in Section 9 be changed to be a more generic OAuth status indicator? It can be used to indicate which scopes were authorized in the success case, or it can be used as status/problem indicator if there was an error. Perhaps the allowed values can be the same as the values defined in the ProblemReporting extension. http://oauth.pbwiki.com/ProblemReporting Allen Dirk Balfanz wrote: On Wed, Nov 19, 2008 at 2:31 PM, Allen Tom [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Since the new hybrid draft spec doesn't affect the OpenID association method, this is moot. However, the spec should mention what SPs should do if the CK is invalid (or doesn't match the realm) in the OpenID authentication request. Presumably, the SP should continue servicing the OpenID portion of the request, however, the response should indicate why the OAuth portion of the request failed. How about, to mimic what happens with association handles, we can return in the response an openid.oauth.invalid_consumer parameter instead of openid.oauth.consumer? It would mean that either the CK was just wrong or that it didn't match the realm. Although at this point it starts to get pretty complicated. Does this error condition really need to be communicated back to the RP? For development etc., it might be enough to just show an error page to the user explaining what happened. Dirk. Allen Dirk Balfanz wrote: I'd recommend an error consistent with Section 8.2.4 in the OpenID 2.0 spec, with a new error_code value indicating that the either the CK or the realm was invalid. There may actually need to be 2 errors, one to indicate that the CK is invalid, and another to indicate that the CK is not valid for the realm. http://openid.net/specs/openid-authentication-2_0.html#anchor20 But Section 8.2 is about the association response. In the auth response, we currently only have cancel or setup_needed. If we invent another error condition there, we're no longer a pure extension. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
A couple minor edits are needed to Section 12: Security Considerations. I assume that the response_token in Section 12 is the same as the request_token in Section 9. The terminology needs to be consistent. Is shoudl be changed to are in the phrase The following security principles is reflected in this design Otherwise, the spec is looking pretty good! Allen Dirk Balfanz wrote: Ok, new version is up. I took out the sentence that recommended to send a cancel. I also added a section on discovery (just copied whatever the AX extension says about that). ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Dirk, typo in Sec 6 The Combined Provider SHOULD in addition obtain, from the Combined Provider, a list . paul Dirk Balfanz wrote: Ok, new spec is up: http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html Dirk. On Mon, Nov 17, 2008 at 5:40 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: [+Brian Eaton] On Mon, Nov 17, 2008 at 4:31 PM, Allen Tom [EMAIL PROTECTED] wrote: Sadly, because the OpenID authentication request is not signed, the CK can't be authenticated, but as you pointed out, although the user may authorize the application, the CK secret is still required to fetch the credentials. The worst that could happen is that a user will authorize an impostor, but the impostor will not be able to retrieve the token. That being said, in our case, the CK contains additional information besides the scope. Yahoo's OAuth Permissions screen contains a lot of rich information including the application's name, description, developer(s), images, authorization lifetimes, etc. Over time, new fields may be added to the approval page. While it might make sense for the application's scope to be passed in at authorization time, does it also make sense to define new parameters for all the other application specific metadata? The actual data that needs to be displayed on an approval page is very SP specific, and some SPs may have security/legal policies requiring that all metadata is manually reviewed, which makes it impossible for metadata to be passed in at runtime. Oh I see. Ok. I'l make a new revision of the spec where I add a required parameter (the consumer key) to the auth request. What should the spec recommend the OP should do if the consumer key and realm don't match? Return a cancel? Return something else? Another change I'll be making is to take out references to unregistered consumers. Brian found a weakness in our approach (the one where we make the association secret the consumer secret) that makes me think we need to think about unregistered consumers a bit more[1]. Dirk. [1] Basically, the problem is that we have oracles around the web that add OAuth signatures to arbitrary requests. They're called OpenSocial gadget containers. If and when OpenID signatures and OAuth signatures converge, with the current propocal we might end up in a situation where my gadget container will create OAuth signatures using the same key needed to assert auth responses. So that's why SPs may need the CK in order to display the Approval page. Make sense? Allen Dirk Balfanz wrote: Need to know the CK for what? What purpose would hinting at the CK serve (since it wouldn't prove ownership)? And don't say "scope" :-) ___ 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.549 / Virus Database: 270.9.6/1797 - Release Date: 18/11/2008 11:23 AM -- ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Tue, Nov 18, 2008 at 10:32 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: On Tue, Nov 18, 2008 at 10:04 PM, Breno de Medeiros [EMAIL PROTECTED] wrote: On Tue, Nov 18, 2008 at 10:00 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: On Tue, Nov 18, 2008 at 6:19 PM, Allen Tom [EMAIL PROTECTED] wrote: Dirk Balfanz wrote: Oh I see. Ok. I'l make a new revision of the spec where I add a required parameter (the consumer key) to the auth request. Cool, thanks! What should the spec recommend the OP should do if the consumer key and realm don't match? Return a cancel? Return something else? I'd recommend an error consistent with Section 8.2.4 in the OpenID 2.0 spec, with a new error_code value indicating that the either the CK or the realm was invalid. There may actually need to be 2 errors, one to indicate that the CK is invalid, and another to indicate that the CK is not valid for the realm. http://openid.net/specs/openid-authentication-2_0.html#anchor20 But Section 8.2 is about the association response. In the auth response, we currently only have cancel or setup_needed. If we invent another error condition there, we're no longer a pure extension. The solution is to add an optional term in the openid.oauth response and return the appropriate error code from the OAuth error handling spec. Well, the oauth errors are about things like the nonce being reused, the signature not verifying, or the request token being revoked. We don't have any of that here. It seems to me that in OpenID, you simply don't return a value if the extension in question encountered some sort of problem. We follow that spirit when the user declines the OAuth request (while, at the same time, approving the authentication request). This error condition (realm not matching the CK), however, feels different. This is more like if the RP violates the both present or both absent rule and sends a claimed if but no identity. As far as I can tell, the spec is silent on what the SP is supposed to do when such inconsistent requests come in. Maybe that's what we should do, too - just say that they have to match, and don't say what should happen if they don't? Sounds good, because such requests may either be accidental or malicious, and the OP might have to deal with them accordingly. Dirk. Dirk. Allen -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Wed, Nov 19, 2008 at 10:14 AM, Breno de Medeiros [EMAIL PROTECTED]wrote: On Tue, Nov 18, 2008 at 10:32 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: On Tue, Nov 18, 2008 at 10:04 PM, Breno de Medeiros [EMAIL PROTECTED] wrote: On Tue, Nov 18, 2008 at 10:00 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: On Tue, Nov 18, 2008 at 6:19 PM, Allen Tom [EMAIL PROTECTED] wrote: Dirk Balfanz wrote: Oh I see. Ok. I'l make a new revision of the spec where I add a required parameter (the consumer key) to the auth request. Cool, thanks! What should the spec recommend the OP should do if the consumer key and realm don't match? Return a cancel? Return something else? I'd recommend an error consistent with Section 8.2.4 in the OpenID 2.0 spec, with a new error_code value indicating that the either the CK or the realm was invalid. There may actually need to be 2 errors, one to indicate that the CK is invalid, and another to indicate that the CK is not valid for the realm. http://openid.net/specs/openid-authentication-2_0.html#anchor20 But Section 8.2 is about the association response. In the auth response, we currently only have cancel or setup_needed. If we invent another error condition there, we're no longer a pure extension. The solution is to add an optional term in the openid.oauth response and return the appropriate error code from the OAuth error handling spec. Well, the oauth errors are about things like the nonce being reused, the signature not verifying, or the request token being revoked. We don't have any of that here. It seems to me that in OpenID, you simply don't return a value if the extension in question encountered some sort of problem. We follow that spirit when the user declines the OAuth request (while, at the same time, approving the authentication request). This error condition (realm not matching the CK), however, feels different. This is more like if the RP violates the both present or both absent rule and sends a claimed if but no identity. As far as I can tell, the spec is silent on what the SP is supposed to do when such inconsistent requests come in. Maybe that's what we should do, too - just say that they have to match, and don't say what should happen if they don't? Sounds good, because such requests may either be accidental or malicious, and the OP might have to deal with them accordingly. Ok, new version is up. I took out the sentence that recommended to send a cancel. I also added a section on discovery (just copied whatever the AX extension says about that). Dirk. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Wed, Nov 19, 2008 at 2:31 PM, Allen Tom [EMAIL PROTECTED] wrote: Since the new hybrid draft spec doesn't affect the OpenID association method, this is moot. However, the spec should mention what SPs should do if the CK is invalid (or doesn't match the realm) in the OpenID authentication request. Presumably, the SP should continue servicing the OpenID portion of the request, however, the response should indicate why the OAuth portion of the request failed. How about, to mimic what happens with association handles, we can return in the response an openid.oauth.invalid_consumer parameter instead of openid.oauth.consumer? It would mean that either the CK was just wrong or that it didn't match the realm. Although at this point it starts to get pretty complicated. Does this error condition really need to be communicated back to the RP? For development etc., it might be enough to just show an error page to the user explaining what happened. Dirk. Allen Dirk Balfanz wrote: I'd recommend an error consistent with Section 8.2.4 in the OpenID 2.0 spec, with a new error_code value indicating that the either the CK or the realm was invalid. There may actually need to be 2 errors, one to indicate that the CK is invalid, and another to indicate that the CK is not valid for the realm. http://openid.net/specs/openid-authentication-2_0.html#anchor20 But Section 8.2 is about the association response. In the auth response, we currently only have cancel or setup_needed. If we invent another error condition there, we're no longer a pure extension. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Ok, new spec is up: http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html Dirk. On Mon, Nov 17, 2008 at 5:40 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: [+Brian Eaton] On Mon, Nov 17, 2008 at 4:31 PM, Allen Tom [EMAIL PROTECTED] wrote: Sadly, because the OpenID authentication request is not signed, the CK can't be authenticated, but as you pointed out, although the user may authorize the application, the CK secret is still required to fetch the credentials. The worst that could happen is that a user will authorize an impostor, but the impostor will not be able to retrieve the token. That being said, in our case, the CK contains additional information besides the scope. Yahoo's OAuth Permissions screen contains a lot of rich information including the application's name, description, developer(s), images, authorization lifetimes, etc. Over time, new fields may be added to the approval page. While it might make sense for the application's scope to be passed in at authorization time, does it also make sense to define new parameters for all the other application specific metadata? The actual data that needs to be displayed on an approval page is very SP specific, and some SPs may have security/legal policies requiring that all metadata is manually reviewed, which makes it impossible for metadata to be passed in at runtime. Oh I see. Ok. I'l make a new revision of the spec where I add a required parameter (the consumer key) to the auth request. What should the spec recommend the OP should do if the consumer key and realm don't match? Return a cancel? Return something else? Another change I'll be making is to take out references to unregistered consumers. Brian found a weakness in our approach (the one where we make the association secret the consumer secret) that makes me think we need to think about unregistered consumers a bit more[1]. Dirk. [1] Basically, the problem is that we have oracles around the web that add OAuth signatures to arbitrary requests. They're called OpenSocial gadget containers. If and when OpenID signatures and OAuth signatures converge, with the current propocal we might end up in a situation where my gadget container will create OAuth signatures using the same key needed to assert auth responses. So that's why SPs may need the CK in order to display the Approval page. Make sense? Allen Dirk Balfanz wrote: Need to know the CK for what? What purpose would hinting at the CK serve (since it wouldn't prove ownership)? And don't say scope :-) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
You have some references like in Section 5. Please change them to in Section 5 of the OAuth Spec. On Tue, Nov 18, 2008 at 11:56 AM, Dirk Balfanz [EMAIL PROTECTED] wrote: Ok, new spec is up: http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html Dirk. On Mon, Nov 17, 2008 at 5:40 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: [+Brian Eaton] On Mon, Nov 17, 2008 at 4:31 PM, Allen Tom [EMAIL PROTECTED] wrote: Sadly, because the OpenID authentication request is not signed, the CK can't be authenticated, but as you pointed out, although the user may authorize the application, the CK secret is still required to fetch the credentials. The worst that could happen is that a user will authorize an impostor, but the impostor will not be able to retrieve the token. That being said, in our case, the CK contains additional information besides the scope. Yahoo's OAuth Permissions screen contains a lot of rich information including the application's name, description, developer(s), images, authorization lifetimes, etc. Over time, new fields may be added to the approval page. While it might make sense for the application's scope to be passed in at authorization time, does it also make sense to define new parameters for all the other application specific metadata? The actual data that needs to be displayed on an approval page is very SP specific, and some SPs may have security/legal policies requiring that all metadata is manually reviewed, which makes it impossible for metadata to be passed in at runtime. Oh I see. Ok. I'l make a new revision of the spec where I add a required parameter (the consumer key) to the auth request. What should the spec recommend the OP should do if the consumer key and realm don't match? Return a cancel? Return something else? Another change I'll be making is to take out references to unregistered consumers. Brian found a weakness in our approach (the one where we make the association secret the consumer secret) that makes me think we need to think about unregistered consumers a bit more[1]. Dirk. [1] Basically, the problem is that we have oracles around the web that add OAuth signatures to arbitrary requests. They're called OpenSocial gadget containers. If and when OpenID signatures and OAuth signatures converge, with the current propocal we might end up in a situation where my gadget container will create OAuth signatures using the same key needed to assert auth responses. So that's why SPs may need the CK in order to display the Approval page. Make sense? Allen Dirk Balfanz wrote: Need to know the CK for what? What purpose would hinting at the CK serve (since it wouldn't prove ownership)? And don't say scope :-) -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Tue, Nov 18, 2008 at 12:00 PM, Breno de Medeiros [EMAIL PROTECTED]wrote: You have some references like in Section 5. Please change them to in Section 5 of the OAuth Spec. But then it would be pointing to the wrong thing :-) in Section 5 means Section 5 of the document the reader is currently reading. Dirk. On Tue, Nov 18, 2008 at 11:56 AM, Dirk Balfanz [EMAIL PROTECTED] wrote: Ok, new spec is up: http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html Dirk. On Mon, Nov 17, 2008 at 5:40 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: [+Brian Eaton] On Mon, Nov 17, 2008 at 4:31 PM, Allen Tom [EMAIL PROTECTED] wrote: Sadly, because the OpenID authentication request is not signed, the CK can't be authenticated, but as you pointed out, although the user may authorize the application, the CK secret is still required to fetch the credentials. The worst that could happen is that a user will authorize an impostor, but the impostor will not be able to retrieve the token. That being said, in our case, the CK contains additional information besides the scope. Yahoo's OAuth Permissions screen contains a lot of rich information including the application's name, description, developer(s), images, authorization lifetimes, etc. Over time, new fields may be added to the approval page. While it might make sense for the application's scope to be passed in at authorization time, does it also make sense to define new parameters for all the other application specific metadata? The actual data that needs to be displayed on an approval page is very SP specific, and some SPs may have security/legal policies requiring that all metadata is manually reviewed, which makes it impossible for metadata to be passed in at runtime. Oh I see. Ok. I'l make a new revision of the spec where I add a required parameter (the consumer key) to the auth request. What should the spec recommend the OP should do if the consumer key and realm don't match? Return a cancel? Return something else? Another change I'll be making is to take out references to unregistered consumers. Brian found a weakness in our approach (the one where we make the association secret the consumer secret) that makes me think we need to think about unregistered consumers a bit more[1]. Dirk. [1] Basically, the problem is that we have oracles around the web that add OAuth signatures to arbitrary requests. They're called OpenSocial gadget containers. If and when OpenID signatures and OAuth signatures converge, with the current propocal we might end up in a situation where my gadget container will create OAuth signatures using the same key needed to assert auth responses. So that's why SPs may need the CK in order to display the Approval page. Make sense? Allen Dirk Balfanz wrote: Need to know the CK for what? What purpose would hinting at the CK serve (since it wouldn't prove ownership)? And don't say scope :-) -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Tue, Nov 18, 2008 at 12:44 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: On Tue, Nov 18, 2008 at 12:00 PM, Breno de Medeiros [EMAIL PROTECTED] wrote: You have some references like in Section 5. Please change them to in Section 5 of the OAuth Spec. But then it would be pointing to the wrong thing :-) in Section 5 means Section 5 of the document the reader is currently reading. Well, the current wording is confusing: consumer key agreed upon in Section 5 (Before Requesting Authentication - Registration). . We did not do anything in Section 5, except vaguely defer to the OAuth spec. Something like consumer key, described in Section 5 (...). Dirk. On Tue, Nov 18, 2008 at 11:56 AM, Dirk Balfanz [EMAIL PROTECTED] wrote: Ok, new spec is up: http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html Dirk. On Mon, Nov 17, 2008 at 5:40 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: [+Brian Eaton] On Mon, Nov 17, 2008 at 4:31 PM, Allen Tom [EMAIL PROTECTED] wrote: Sadly, because the OpenID authentication request is not signed, the CK can't be authenticated, but as you pointed out, although the user may authorize the application, the CK secret is still required to fetch the credentials. The worst that could happen is that a user will authorize an impostor, but the impostor will not be able to retrieve the token. That being said, in our case, the CK contains additional information besides the scope. Yahoo's OAuth Permissions screen contains a lot of rich information including the application's name, description, developer(s), images, authorization lifetimes, etc. Over time, new fields may be added to the approval page. While it might make sense for the application's scope to be passed in at authorization time, does it also make sense to define new parameters for all the other application specific metadata? The actual data that needs to be displayed on an approval page is very SP specific, and some SPs may have security/legal policies requiring that all metadata is manually reviewed, which makes it impossible for metadata to be passed in at runtime. Oh I see. Ok. I'l make a new revision of the spec where I add a required parameter (the consumer key) to the auth request. What should the spec recommend the OP should do if the consumer key and realm don't match? Return a cancel? Return something else? Another change I'll be making is to take out references to unregistered consumers. Brian found a weakness in our approach (the one where we make the association secret the consumer secret) that makes me think we need to think about unregistered consumers a bit more[1]. Dirk. [1] Basically, the problem is that we have oracles around the web that add OAuth signatures to arbitrary requests. They're called OpenSocial gadget containers. If and when OpenID signatures and OAuth signatures converge, with the current propocal we might end up in a situation where my gadget container will create OAuth signatures using the same key needed to assert auth responses. So that's why SPs may need the CK in order to display the Approval page. Make sense? Allen Dirk Balfanz wrote: Need to know the CK for what? What purpose would hinting at the CK serve (since it wouldn't prove ownership)? And don't say scope :-) -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Dirk Balfanz wrote: Oh I see. Ok. I'l make a new revision of the spec where I add a required parameter (the consumer key) to the auth request. Cool, thanks! What should the spec recommend the OP should do if the consumer key and realm don't match? Return a cancel? Return something else? I'd recommend an error consistent with Section 8.2.4 in the OpenID 2.0 spec, with a new error_code value indicating that the either the CK or the realm was invalid. There may actually need to be 2 errors, one to indicate that the CK is invalid, and another to indicate that the CK is not valid for the realm. http://openid.net/specs/openid-authentication-2_0.html#anchor20 Allen ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Manger, James H wrote: Ideally, an app would attempt to access a protected resource at an SP and get: * A 401 Unauthenticated response from the SP; with * A “WWW-Authenticate: OAuth” header; with * A parameter providing the authorization URL; and * Another parameter with the OP URL (when OpenID/OAuth hybrid was supported). One problem with this approach is that many SPs like Yahoo and MySpace will require developers to register their site to get a Consumer Key. Given that the developer already has to manually get a CK, there might not that much value in defining a workflow for Consumers to discover the OAuth endpoints. Allen ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Tue, Nov 18, 2008 at 6:26 PM, Allen Tom [EMAIL PROTECTED] wrote: Manger, James H wrote: Ideally, an app would attempt to access a protected resource at an SP and get: * A 401 Unauthenticated response from the SP; with * A WWW-Authenticate: OAuth header; with * A parameter providing the authorization URL; and * Another parameter with the OP URL (when OpenID/OAuth hybrid was supported). One problem with this approach is that many SPs like Yahoo and MySpace will require developers to register their site to get a Consumer Key. Given that the developer already has to manually get a CK, there might not that much value in defining a workflow for Consumers to discover the OAuth endpoints. I believe this technical problem will be solved anyway by the integrated OpenID/OAuth discovery mechanism via XRD (currently under discussion). As Allen remarks, though, its value will be limited while manual registration is required by most service providers. Allen ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Dirk Balfanz wrote: Ok, new spec is up: http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html Hi Dirk, It doesn't look like the hybrid spec changes the OpenID association mechanism, so you should not mention the association mechanism in the last sentence of Section 3. Under Security Considerations in Section 11, it would probably be good to mention that anyone knowing the CK can force the SP to display the hybrid approval page, while standard OAuth requires both the CK and the CSecret to display a vanilla OAuth approval page. Thanks Allen ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Allen Tom wrote: Manger, James H wrote: Ideally, an app would attempt to access a protected resource at an SP and get: * A 401 Unauthenticated response from the SP; with * A “WWW-Authenticate: OAuth” header; with * A parameter providing the authorization URL; and * Another parameter with the OP URL (when OpenID/OAuth hybrid was supported). One problem with this approach is that many SPs like Yahoo and MySpace will require developers to register their site to get a Consumer Key. Given that the developer already has to manually get a CK, there might not that much value in defining a workflow for Consumers to discover the OAuth endpoints. As long as this is true it will be impossible for such SPs to expose non-proprietary protocols like PortableContacts, so either these SPs will need to find a way to work without pre-registration or we'll all have to accept that the open stack is impossible and go find something more productive to do. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Tue, Nov 18, 2008 at 7:45 PM, Martin Atkins [EMAIL PROTECTED] wrote: Allen Tom wrote: Manger, James H wrote: Ideally, an app would attempt to access a protected resource at an SP and get: * A 401 Unauthenticated response from the SP; with * A WWW-Authenticate: OAuth header; with * A parameter providing the authorization URL; and * Another parameter with the OP URL (when OpenID/OAuth hybrid was supported). One problem with this approach is that many SPs like Yahoo and MySpace will require developers to register their site to get a Consumer Key. Given that the developer already has to manually get a CK, there might not that much value in defining a workflow for Consumers to discover the OAuth endpoints. As long as this is true it will be impossible for such SPs to expose non-proprietary protocols like PortableContacts, so either these SPs will need to find a way to work without pre-registration or we'll all have to accept that the open stack is impossible and go find something more productive to do. At this point, there is no reasonably secure formulation of OAuth without key registration. We hope to add one for the hybrid protocol. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Tue, Nov 18, 2008 at 7:57 PM, Martin Atkins [EMAIL PROTECTED] wrote: Breno de Medeiros wrote: At this point, there is no reasonably secure formulation of OAuth without key registration. We hope to add one for the hybrid protocol. If that is true then OAuth is broken. Wouldn't it be better to fix this problem in OAuth itself rather than only in the hybrid protocol? Addressing it at the level of the OAuth spec may be useful also, but it is not really desirable to have the request token step in the hybrid protocol for performance reasons. And any such fix for OAuth that will work also for desktop apps will probably involve the request token step (in fact it is not too hard to envision some strategies along those lines). Mobile and desktop apps need to be able to use OAuth as well, and since consumer secrets are impractical for such apps there has to be a way to use OAuth without consumer secrets in order to support them. The hybrid protocol is not appropriate for desktop/mobile apps, so fixing it at this level does not address the problem. Cheers, Martin -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Tue, Nov 18, 2008 at 10:00 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: On Tue, Nov 18, 2008 at 6:19 PM, Allen Tom [EMAIL PROTECTED] wrote: Dirk Balfanz wrote: Oh I see. Ok. I'l make a new revision of the spec where I add a required parameter (the consumer key) to the auth request. Cool, thanks! What should the spec recommend the OP should do if the consumer key and realm don't match? Return a cancel? Return something else? I'd recommend an error consistent with Section 8.2.4 in the OpenID 2.0 spec, with a new error_code value indicating that the either the CK or the realm was invalid. There may actually need to be 2 errors, one to indicate that the CK is invalid, and another to indicate that the CK is not valid for the realm. http://openid.net/specs/openid-authentication-2_0.html#anchor20 But Section 8.2 is about the association response. In the auth response, we currently only have cancel or setup_needed. If we invent another error condition there, we're no longer a pure extension. The solution is to add an optional term in the openid.oauth response and return the appropriate error code from the OAuth error handling spec. Dirk. Allen -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Tue, Nov 18, 2008 at 10:04 PM, Breno de Medeiros [EMAIL PROTECTED] wrote: On Tue, Nov 18, 2008 at 10:00 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: On Tue, Nov 18, 2008 at 6:19 PM, Allen Tom [EMAIL PROTECTED] wrote: Dirk Balfanz wrote: Oh I see. Ok. I'l make a new revision of the spec where I add a required parameter (the consumer key) to the auth request. Cool, thanks! What should the spec recommend the OP should do if the consumer key and realm don't match? Return a cancel? Return something else? I'd recommend an error consistent with Section 8.2.4 in the OpenID 2.0 spec, with a new error_code value indicating that the either the CK or the realm was invalid. There may actually need to be 2 errors, one to indicate that the CK is invalid, and another to indicate that the CK is not valid for the realm. http://openid.net/specs/openid-authentication-2_0.html#anchor20 But Section 8.2 is about the association response. In the auth response, we currently only have cancel or setup_needed. If we invent another error condition there, we're no longer a pure extension. The solution is to add an optional term in the openid.oauth response and return the appropriate error code from the OAuth error handling spec. Actually, I meant a required term, to be present only in unsuccessful OAuth responses Dirk. Allen -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Tue, Nov 18, 2008 at 6:58 PM, Allen Tom [EMAIL PROTECTED] wrote: Dirk Balfanz wrote: Ok, new spec is up: http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html Hi Dirk, It doesn't look like the hybrid spec changes the OpenID association mechanism, so you should not mention the association mechanism in the last sentence of Section 3. Good catch. I took out the whole sentence. Under Security Considerations in Section 11, it would probably be good to mention that anyone knowing the CK can force the SP to display the hybrid approval page, while standard OAuth requires both the CK and the CSecret to display a vanilla OAuth approval page. Good idea. I added a paragraph in Section 11 explaining this. Dirk. Thanks Allen ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Tue, Nov 18, 2008 at 10:04 PM, Breno de Medeiros [EMAIL PROTECTED]wrote: On Tue, Nov 18, 2008 at 10:00 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: On Tue, Nov 18, 2008 at 6:19 PM, Allen Tom [EMAIL PROTECTED] wrote: Dirk Balfanz wrote: Oh I see. Ok. I'l make a new revision of the spec where I add a required parameter (the consumer key) to the auth request. Cool, thanks! What should the spec recommend the OP should do if the consumer key and realm don't match? Return a cancel? Return something else? I'd recommend an error consistent with Section 8.2.4 in the OpenID 2.0 spec, with a new error_code value indicating that the either the CK or the realm was invalid. There may actually need to be 2 errors, one to indicate that the CK is invalid, and another to indicate that the CK is not valid for the realm. http://openid.net/specs/openid-authentication-2_0.html#anchor20 But Section 8.2 is about the association response. In the auth response, we currently only have cancel or setup_needed. If we invent another error condition there, we're no longer a pure extension. The solution is to add an optional term in the openid.oauth response and return the appropriate error code from the OAuth error handling spec. Well, the oauth errors are about things like the nonce being reused, the signature not verifying, or the request token being revoked. We don't have any of that here. It seems to me that in OpenID, you simply don't return a value if the extension in question encountered some sort of problem. We follow that spirit when the user declines the OAuth request (while, at the same time, approving the authentication request). This error condition (realm not matching the CK), however, feels different. This is more like if the RP violates the both present or both absent rule and sends a claimed if but no identity. As far as I can tell, the spec is silent on what the SP is supposed to do when such inconsistent requests come in. Maybe that's what we should do, too - just say that they have to match, and don't say what should happen if they don't? Dirk. Dirk. Allen -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Dirk Balfanz wrote: So, again, the proposal seems to be to embed a hint to the consumer key into the association request (which will then be threaded through the association handle into the auth request). This doesn't buy us any additional security, it just hints at what scope the consumer is allowed to request (for those SPs that encode scope in consumer keys) - the security is provided later in the access token request step. It's unfortunate that the OpenID Authentication request isn't signed, because if it was signed, it would be nearly equivalent to OAuth, because an OAuth approval page is only displayed using a valid Request Token that was returned via a signed request. Now, my argument is that we already _have_ a place to signal scope. It's the openid.oauth.scope parameter. Yes, but as Breno said, the OAuth spec does not currently have a concept of scope, however, the Consumer Key is definitely part of the spec. It would seem to be more generally useful for a Consumer to signal Consumer Key, rather than signaling scope, as many SPs need to know the CK, but not all of them will need to know the scope. That being said, the CK and Scope should just be 2 separate parameters. If you don't want to put consumer keys there, let consumers put some other encoding of the scope there. I have no problem with having an optional parameter for CK, and a different optional parameter for scope. Allen ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Yes, but as Breno said, the OAuth spec does not currently have a concept of scope, however, the Consumer Key is definitely part of the spec. It would seem to be more generally useful for a Consumer to signal Consumer Key, rather than signaling scope, as many SPs need to know the CK, but not all of them will need to know the scope. That being said, the CK and Scope should Need to know the CK for what? What purpose would hinting at the CK serve (since it wouldn't prove ownership)? And don't say scope :-) Dirk. just be 2 separate parameters. If you don't want to put consumer keys there, let consumers put some other encoding of the scope there. I have no problem with having an optional parameter for CK, and a different optional parameter for scope. Allen ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Sadly, because the OpenID authentication request is not signed, the CK can't be authenticated, but as you pointed out, although the user may authorize the application, the CK secret is still required to fetch the credentials. The worst that could happen is that a user will authorize an impostor, but the impostor will not be able to retrieve the token. That being said, in our case, the CK contains additional information besides the scope. Yahoo's OAuth Permissions screen contains a lot of rich information including the application's name, description, developer(s), images, authorization lifetimes, etc. Over time, new fields may be added to the approval page. While it might make sense for the application's scope to be passed in at authorization time, does it also make sense to define new parameters for all the other application specific metadata? The actual data that needs to be displayed on an approval page is very SP specific, and some SPs may have security/legal policies requiring that all metadata is manually reviewed, which makes it impossible for metadata to be passed in at runtime. So that's why SPs may need the CK in order to display the Approval page. Make sense? Allen Dirk Balfanz wrote: Need to know the CK for what? What purpose would hinting at the CK serve (since it wouldn't prove ownership)? And don't say scope :-) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
[+Brian Eaton] On Mon, Nov 17, 2008 at 4:31 PM, Allen Tom [EMAIL PROTECTED] wrote: Sadly, because the OpenID authentication request is not signed, the CK can't be authenticated, but as you pointed out, although the user may authorize the application, the CK secret is still required to fetch the credentials. The worst that could happen is that a user will authorize an impostor, but the impostor will not be able to retrieve the token. That being said, in our case, the CK contains additional information besides the scope. Yahoo's OAuth Permissions screen contains a lot of rich information including the application's name, description, developer(s), images, authorization lifetimes, etc. Over time, new fields may be added to the approval page. While it might make sense for the application's scope to be passed in at authorization time, does it also make sense to define new parameters for all the other application specific metadata? The actual data that needs to be displayed on an approval page is very SP specific, and some SPs may have security/legal policies requiring that all metadata is manually reviewed, which makes it impossible for metadata to be passed in at runtime. Oh I see. Ok. I'l make a new revision of the spec where I add a required parameter (the consumer key) to the auth request. What should the spec recommend the OP should do if the consumer key and realm don't match? Return a cancel? Return something else? Another change I'll be making is to take out references to unregistered consumers. Brian found a weakness in our approach (the one where we make the association secret the consumer secret) that makes me think we need to think about unregistered consumers a bit more[1]. Dirk. [1] Basically, the problem is that we have oracles around the web that add OAuth signatures to arbitrary requests. They're called OpenSocial gadget containers. If and when OpenID signatures and OAuth signatures converge, with the current propocal we might end up in a situation where my gadget container will create OAuth signatures using the same key needed to assert auth responses. So that's why SPs may need the CK in order to display the Approval page. Make sense? Allen Dirk Balfanz wrote: Need to know the CK for what? What purpose would hinting at the CK serve (since it wouldn't prove ownership)? And don't say scope :-) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Dirk, Allen, Brian, etc How about sending an ‘unauthorized request token’ with the OpenID authentication request, instead of a scope or a consumer key? A Service Provider can choose to encode the consumer key or scope into the request token when issuing it if they need those details when interacting with the user. From the OAuth perspective there would be minimal change to the protocol. Instead of redirecting the user to the authorization URL (after adding the token), the user is redirected to the OP URL (after adding the token). That makes it easier to be confident that the hybrid model does not introduce new security weaknesses. Ideally, an app would attempt to access a protected resource at an SP and get: * A 401 Unauthenticated response from the SP; with * A “WWW-Authenticate: OAuth” header; with * A parameter providing the authorization URL; and * Another parameter with the OP URL (when OpenID/OAuth hybrid was supported). If the app supports the hybrid mode, and the SP has indicated it supports the hybrid mode by including an OP URL in a 401 response, and the user’s OpenID identifier resolves (via discovery) to the same OP, then the app can trigger the hybrid auth/authz action. James Manger ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
I don't want to put parameters into the protocol that aren't necessary. So far, I've heard one argument for adding the consumer key in the association request: to give a hint to the authorization UI as to whether or not the consumer is authorized to request the scope passed in the openid.oauth.scope parameter. The idea is, as far as I can tell, to encode the consumer key into the association handle, and thus have the consumer key available at authorization time. I'm saying hint, because it is nothing more than that - neither the association request nor the auth request are signed, and the consumer can put whatever they want into the consumer key (in the association request) or association handle (in the auth request). Which is fine, since an attacker lying about these things won't be able to exchange the request token for an access token later. So, again, the proposal seems to be to embed a hint to the consumer key into the association request (which will then be threaded through the association handle into the auth request). This doesn't buy us any additional security, it just hints at what scope the consumer is allowed to request (for those SPs that encode scope in consumer keys) - the security is provided later in the access token request step. Now, my argument is that we already _have_ a place to signal scope. It's the openid.oauth.scope parameter. If you don't want to put consumer keys there, let consumers put some other encoding of the scope there. If you're an OP where scope isn't really decided at authorization time (but later, when we know the real consumer key of the consumer), then this will just be a hint for you to get the UI right. But that's no different from putting the consumer key into the association request - that's only a hint, too. So we get the same guarantees with less parameters if we stick with the proposal. Right? :-) Dirk. On Thu, Nov 13, 2008 at 8:32 PM, Breno de Medeiros [EMAIL PROTECTED] wrote: I changed my mind on this one. A. The fact that scopes are not standardized in OAuth today does not mean that in the future *some* scopes (e.g., related to portable contacts) may be standardized. B. The consumer key is an intrinsic identifier of the party requesting association and probably should be included, with the realm, in the association request (if available). There is no need, however, to include any additional information in the authentication request. The consumer key can be bound to the association handle. On Thu, Nov 13, 2008 at 6:43 PM, Allen Tom [EMAIL PROTECTED] wrote: In the future, we might update our OAuth service to allow developers to pass us the scope dynamically, rather than binding the scope to the CK. However, we'd still probably require developers to agree to a TOS in order to get a CK/CS. I'm concerned about having to tell developers to pass the CK via the scope parameter for the first revision, and then later telling them that scope parameter actually means the scope. I'd like to have one parameter (possibly optional) that means CK, and another parameter (also optional) that means Scope. Overloading a single parameter can get really messy in the long run. Allen Breno de Medeiros wrote: Ok, but what is wrong for you to instruct the developers to insert the consumer_key in the scope parameter, and they bind it to the approved request token? -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Hi Yariv, In the registered consumer case, the SP will need the Consumer Key to show the Approval page. Previous versions of the spec had the Request Token in the OpenID Authentication request, which allowed the SP to derive the Consumer Key from the Request Token. At the IIW, we had discussed somehow tying the Association Handle to the Consumer Key. Regardless of the solution, the SP will need to be know the Consumer Key in order to properly identify the OAuth Consumer when displaying the Approval page. The OpenID Realm is not quite sufficient, at least for SPs which require consumers to pre-register for a CK. One possible optimization would be to just use the Consumer Key as the OpenID Association Handle, and Consumer Secret as the OpenID Association. The Consumer can just sign the OpenID Auth request using its CK/CS and the OP can return a pre-approved response token in the OpenID assertion. The Consumer can then exchange the response token for the OAuth Access Token/ ATS. Thoughts? Allen Yariv Adan wrote: Following the IIW session on this topic, we updated the spec in http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html to address the issues that were raised. Especially, optimizing on how OAuth request token is handled, allowed to remove one full roundtrip! Would appreciate any feedback on the updated suggestion. Thanks On Mon, Nov 3, 2008 at 12:00 PM, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Send specs mailing list submissions to specs@openid.net mailto:specs@openid.net To subscribe or unsubscribe via the World Wide Web, visit http://openid.net/mailman/listinfo/specs or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of specs digest... Today's Topics: 1. Proposal to create the OpenID OAuth Hybrid Working Group (Yariv Adan) -- Message: 1 Date: Mon, 3 Nov 2008 15:30:57 +0100 From: Yariv Adan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Subject: Proposal to create the OpenID OAuth Hybrid Working Group To: specs@openid.net mailto:specs@openid.net Message-ID: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 In accordance with the OpenID Foundation IPR policies and procedures http://openid.net/foundation/intellectual-property/ this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: Background Information: OpenID has always been focused on how to enable user-authentication within the browser. Over the last year, OAuth has been developed to allow authorization either from within a browser, desktop software, or mobile devices. Obviously there has been interest in using OpenID and OAuth together allowing a user to share their identity as well as grant a Relying Party access to an OAuth protected resource in a single step. A small group of people have been working on developing an extension to OpenID which makes this possible in a collaborative fashion within http://code.google.com/p/step2/. This small project includes a draft spec and Open Source implementations which the proposers would like to finalize within the OpenID Foundation. Working Group Name: OpenID OAuth Hybrid Working Group Purpose: Produce a standard OpenID extension to the OpenID Authentication protocol that provides a mechanism to embed an OAuth approval request into an OpenID authentication request to permit combined user approval. The extension addresses the use case where the OpenID Provider and OAuth Service Provider are the same service. To provide good user experience, it is important to present a combined authentication and authorization screen for the two protocols. Scope: Standardize the draft Hybrid Protocol ( http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html) as an official OpenID Extension describing how to combine an OpenID authentication request with the approval of an OAuth request token. Anticipated Contributions: Draft specification referenced above and various text contributions as more developers implement it. Proposed List of Specifications: OpenID OAuth Extension 1.0. Spec completion by Q4 2008. Anticipated audience or users of the work: - OpenID Providers and
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Thu, Nov 13, 2008 at 12:46 PM, Allen Tom [EMAIL PROTECTED] wrote: Hi Yariv, In the registered consumer case, the SP will need the Consumer Key to show the Approval page. Previous versions of the spec had the Request Token in the OpenID Authentication request, which allowed the SP to derive the Consumer Key from the Request Token. At the IIW, we had discussed somehow tying the Association Handle to the Consumer Key. Regardless of the solution, the SP will need to be know the Consumer Key in order to properly identify the OAuth Consumer when displaying the Approval page. The OpenID Realm is not quite sufficient, at least for SPs which require consumers to pre-register for a CK. I don't think this is true - I believe the realm is sufficient. Let me try and explain. (We'll assume registered consumers.) On the approval page, we need to identify the consumer. In its current form, the spec basically assumes that you're gonna use the realm for that. Let's assume that The Bad Guy somehow managed to sneak a misleading realm into a request, i.e. the user sees the realm on the login page and clicks approve when he wouldn't have approved had he known the real identity of The Bad Guy. The OP embeds, in the request token, the realm to which the request token was issued. Later, when The Bad Guy tries to exchange the request token for an access token, it won't work, b/c The Bad Guy only has access to his own consumer secret, which doesn't match the realm embedded in the request token. So we _do_ have a binding from the request token to the consumer key, it's just enforced later, not at approval time. Does this make sense, or am I missing something? Dirk. One possible optimization would be to just use the Consumer Key as the OpenID Association Handle, and Consumer Secret as the OpenID Association. The Consumer can just sign the OpenID Auth request using its CK/CS and the OP can return a pre-approved response token in the OpenID assertion. The Consumer can then exchange the response token for the OAuth Access Token/ ATS. Thoughts? Allen Yariv Adan wrote: Following the IIW session on this topic, we updated the spec in http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.htmlto address the issues that were raised. Especially, optimizing on how OAuth request token is handled, allowed to remove one full roundtrip! Would appreciate any feedback on the updated suggestion. Thanks On Mon, Nov 3, 2008 at 12:00 PM, [EMAIL PROTECTED] wrote: Send specs mailing list submissions to specs@openid.net To subscribe or unsubscribe via the World Wide Web, visit http://openid.net/mailman/listinfo/specs or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of specs digest... Today's Topics: 1. Proposal to create the OpenID OAuth Hybrid Working Group (Yariv Adan) -- Message: 1 Date: Mon, 3 Nov 2008 15:30:57 +0100 From: Yariv Adan [EMAIL PROTECTED] Subject: Proposal to create the OpenID OAuth Hybrid Working Group To: specs@openid.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 In accordance with the OpenID Foundation IPR policies and procedures http://openid.net/foundation/intellectual-property/ this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: Background Information: OpenID has always been focused on how to enable user-authentication within the browser. Over the last year, OAuth has been developed to allow authorization either from within a browser, desktop software, or mobile devices. Obviously there has been interest in using OpenID and OAuth together allowing a user to share their identity as well as grant a Relying Party access to an OAuth protected resource in a single step. A small group of people have been working on developing an extension to OpenID which makes this possible in a collaborative fashion within http://code.google.com/p/step2/. This small project includes a draft spec and Open Source implementations which the proposers would like to finalize within the OpenID Foundation. Working Group Name: OpenID OAuth Hybrid Working Group Purpose: Produce a standard OpenID extension to the OpenID Authentication protocol that provides a mechanism to embed an OAuth approval request into an OpenID authentication request to permit combined user approval. The extension addresses the use case where the OpenID Provider and OAuth Service Provider are the same service. To provide good user experience, it is important to present a combined
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Dirk Balfanz wrote: I don't think this is true - I believe the realm is sufficient. Let me try and explain. (We'll assume registered consumers.) On the approval page, we need to identify the consumer. In its current form, the spec basically assumes that you're gonna use the realm for that. You're assuming that a realm has only one CK. A site might have multiple consumer keys, with different scopes attached to them... Allen ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
I think so. What about cases where two descrete applications/consumers share a realm? Sent from a mobile device. On Nov 13, 2008, at 3:58 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: On Thu, Nov 13, 2008 at 12:46 PM, Allen Tom [EMAIL PROTECTED] wrote: Hi Yariv, In the registered consumer case, the SP will need the Consumer Key to show the Approval page. Previous versions of the spec had the Request Token in the OpenID Authentication request, which allowed the SP to derive the Consumer Key from the Request Token. At the IIW, we had discussed somehow tying the Association Handle to the Consumer Key. Regardless of the solution, the SP will need to be know the Consumer Key in order to properly identify the OAuth Consumer when displaying the Approval page. The OpenID Realm is not quite sufficient, at least for SPs which require consumers to pre-register for a CK. I don't think this is true - I believe the realm is sufficient. Let me try and explain. (We'll assume registered consumers.) On the approval page, we need to identify the consumer. In its current form, the spec basically assumes that you're gonna use the realm for that. Let's assume that The Bad Guy somehow managed to sneak a misleading realm into a request, i.e. the user sees the realm on the login page and clicks approve when he wouldn't have approved had he known the real identity of The Bad Guy. The OP embeds, in the request token, the realm to which the request token was issued. Later, when The Bad Guy tries to exchange the request token for an access token, it won't work, b/c The Bad Guy only has access to his own consumer secret, which doesn't match the realm embedded in the request token. So we _do_ have a binding from the request token to the consumer key, it's just enforced later, not at approval time. Does this make sense, or am I missing something? Dirk. One possible optimization would be to just use the Consumer Key as the OpenID Association Handle, and Consumer Secret as the OpenID Association. The Consumer can just sign the OpenID Auth request using its CK/CS and the OP can return a pre-approved response token in the OpenID assertion. The Consumer can then exchange the response token for the OAuth Access Token/ ATS. Thoughts? Allen Yariv Adan wrote: Following the IIW session on this topic, we updated the spec in http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html to address the issues that were raised. Especially, optimizing on how OAuth request token is handled, allowed to remove one full roundtrip! Would appreciate any feedback on the updated suggestion. Thanks On Mon, Nov 3, 2008 at 12:00 PM, [EMAIL PROTECTED] wrote: Send specs mailing list submissions to specs@openid.net To subscribe or unsubscribe via the World Wide Web, visit http://openid.net/mailman/listinfo/specs or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of specs digest... Today's Topics: 1. Proposal to create the OpenID OAuth Hybrid Working Group (Yariv Adan) --- --- Message: 1 Date: Mon, 3 Nov 2008 15:30:57 +0100 From: Yariv Adan [EMAIL PROTECTED] Subject: Proposal to create the OpenID OAuth Hybrid Working Group To: specs@openid.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 In accordance with the OpenID Foundation IPR policies and procedures http://openid.net/foundation/intellectual-property/ this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: Background Information: OpenID has always been focused on how to enable user-authentication within the browser. Over the last year, OAuth has been developed to allow authorization either from within a browser, desktop software, or mobile devices. Obviously there has been interest in using OpenID and OAuth together allowing a user to share their identity as well as grant a Relying Party access to an OAuth protected resource in a single step. A small group of people have been working on developing an extension to OpenID which makes this possible in a collaborative fashion within http://code.google.com/p/step2/. This small project includes a draft spec and Open Source implementations which the proposers would like to finalize within the OpenID Foundation. Working Group Name: OpenID OAuth Hybrid Working Group Purpose: Produce a standard OpenID extension to the OpenID Authentication protocol that provides a mechanism to embed an OAuth approval request into an OpenID authentication request to permit
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom [EMAIL PROTECTED] wrote: Dirk Balfanz wrote: I don't think this is true - I believe the realm is sufficient. Let me try and explain. (We'll assume registered consumers.) On the approval page, we need to identify the consumer. In its current form, the spec basically assumes that you're gonna use the realm for that. You're assuming that a realm has only one CK. A site might have multiple consumer keys, with different scopes attached to them... Actually, I wasn't assuming that. At access token request time, you follow the map from consumer-key to realm (that's the direction you can do, right)? If that's a many-to-one map then this will give you one realm. Then you check whether that's the realm that the request token was issued to. The one thing you're losing is that you can't, at approval time, figure out whether that realm is requesting a scope that they have access to. So a realm could ask for a certain scope in their auth request, the user approves it, and then at access-token-request time, you won't issue the token b/c they're using a CK that doesn't have enough privileges. It's still secure, but gives you a crappy user experience if the consumer mixes up their CKs. Wait - I think I have an idea: what if the Yahoo-specific way of requesting the scope is to include the CK into the openid.oauth.scope parameter? That way, you can at approval time make sure that they are requesting a scope that they are actually authorized to pick up. This wouldn't be for security purposes - just as a way to make sure the user experience isn't surprising. Dirk. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Thu, Nov 13, 2008 at 1:58 PM, Darren Bounds [EMAIL PROTECTED] wrote: I think so. What about cases where two descrete applications/consumers share a realm? You think it makes sense, or that I'm missing something? :-) Anyway, are those two applications that have nothing to do with each other? If so, then they're probably not going to share a realm. After all, which application are we logging the user into? If it's the case that Allen is bringing up, and this is really the same application just using different consumer keys for different purposes, then I think we're fine - a mapping from consumer key to (one) realm should suffice. Dirk. Sent from a mobile device. On Nov 13, 2008, at 3:58 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: On Thu, Nov 13, 2008 at 12:46 PM, Allen Tom [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Yariv, In the registered consumer case, the SP will need the Consumer Key to show the Approval page. Previous versions of the spec had the Request Token in the OpenID Authentication request, which allowed the SP to derive the Consumer Key from the Request Token. At the IIW, we had discussed somehow tying the Association Handle to the Consumer Key. Regardless of the solution, the SP will need to be know the Consumer Key in order to properly identify the OAuth Consumer when displaying the Approval page. The OpenID Realm is not quite sufficient, at least for SPs which require consumers to pre-register for a CK. I don't think this is true - I believe the realm is sufficient. Let me try and explain. (We'll assume registered consumers.) On the approval page, we need to identify the consumer. In its current form, the spec basically assumes that you're gonna use the realm for that. Let's assume that The Bad Guy somehow managed to sneak a misleading realm into a request, i.e. the user sees the realm on the login page and clicks approve when he wouldn't have approved had he known the real identity of The Bad Guy. The OP embeds, in the request token, the realm to which the request token was issued. Later, when The Bad Guy tries to exchange the request token for an access token, it won't work, b/c The Bad Guy only has access to his own consumer secret, which doesn't match the realm embedded in the request token. So we _do_ have a binding from the request token to the consumer key, it's just enforced later, not at approval time. Does this make sense, or am I missing something? Dirk. One possible optimization would be to just use the Consumer Key as the OpenID Association Handle, and Consumer Secret as the OpenID Association. The Consumer can just sign the OpenID Auth request using its CK/CS and the OP can return a pre-approved response token in the OpenID assertion. The Consumer can then exchange the response token for the OAuth Access Token/ ATS. Thoughts? Allen Yariv Adan wrote: Following the IIW session on this topic, we updated the spec in http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.htmlto address the issues that were raised. Especially, optimizing on how OAuth request token is handled, allowed to remove one full roundtrip! Would appreciate any feedback on the updated suggestion. Thanks On Mon, Nov 3, 2008 at 12:00 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Send specs mailing list submissions to specs@openid.netspecs@openid.net To subscribe or unsubscribe via the World Wide Web, visit http://openid.net/mailman/listinfo/specs http://openid.net/mailman/listinfo/specs or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED][EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED][EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of specs digest... Today's Topics: 1. Proposal to create the OpenID OAuth Hybrid Working Group (Yariv Adan) -- Message: 1 Date: Mon, 3 Nov 2008 15:30:57 +0100 From: Yariv Adan [EMAIL PROTECTED][EMAIL PROTECTED] Subject: Proposal to create the OpenID OAuth Hybrid Working Group To: specs@openid.netspecs@openid.net Message-ID: [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 In accordance with the OpenID Foundation IPR policies and procedures http://openid.net/foundation/intellectual-property/ http://openid.net/foundation/intellectual-property/ this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: Background Information: OpenID has always been focused on how to enable user-authentication within the browser. Over the last
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Certainly but the consumer context you display to the user is falsely represented based solely on the realm in that circumstance. Sent from a mobile device. On Nov 13, 2008, at 4:58 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom [EMAIL PROTECTED] wrote: Dirk Balfanz wrote: I don't think this is true - I believe the realm is sufficient. Let me try and explain. (We'll assume registered consumers.) On the approval page, we need to identify the consumer. In its current form, the spec basically assumes that you're gonna use the realm for that. You're assuming that a realm has only one CK. A site might have multiple consumer keys, with different scopes attached to them... Actually, I wasn't assuming that. At access token request time, you follow the map from consumer-key to realm (that's the direction you can do, right)? If that's a many-to-one map then this will give you one realm. Then you check whether that's the realm that the request token was issued to. The one thing you're losing is that you can't, at approval time, figure out whether that realm is requesting a scope that they have access to. So a realm could ask for a certain scope in their auth request, the user approves it, and then at access-token-request time, you won't issue the token b/c they're using a CK that doesn't have enough privileges. It's still secure, but gives you a crappy user experience if the consumer mixes up their CKs. Wait - I think I have an idea: what if the Yahoo-specific way of requesting the scope is to include the CK into the openid.oauth.scope parameter? That way, you can at approval time make sure that they are requesting a scope that they are actually authorized to pick up. This wouldn't be for security purposes - just as a way to make sure the user experience isn't surprising. Dirk. ___ 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: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Yes, I can see how that would happen. So how about for OPs who tie scope to Consumer Keys, their openid.oauth.scope syntax would look something like this: openid.oauth.scope=consumer_key:scope1,scope2,scope3 Or, if there is a one-to-one mapping from consumer_key to scope, simply like this: openid.oauth.scope=consumer_key Dirk. On Thu, Nov 13, 2008 at 2:04 PM, Darren Bounds [EMAIL PROTECTED] wrote: Certainly but the consumer context you display to the user is falsely represented based solely on the realm in that circumstance. Sent from a mobile device. On Nov 13, 2008, at 4:58 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Dirk Balfanz wrote: I don't think this is true - I believe the realm is sufficient. Let me try and explain. (We'll assume registered consumers.) On the approval page, we need to identify the consumer. In its current form, the spec basically assumes that you're gonna use the realm for that. You're assuming that a realm has only one CK. A site might have multiple consumer keys, with different scopes attached to them... Actually, I wasn't assuming that. At access token request time, you follow the map from consumer-key to realm (that's the direction you can do, right)? If that's a many-to-one map then this will give you one realm. Then you check whether that's the realm that the request token was issued to. The one thing you're losing is that you can't, at approval time, figure out whether that realm is requesting a scope that they have access to. So a realm could ask for a certain scope in their auth request, the user approves it, and then at access-token-request time, you won't issue the token b/c they're using a CK that doesn't have enough privileges. It's still secure, but gives you a crappy user experience if the consumer mixes up their CKs. Wait - I think I have an idea: what if the Yahoo-specific way of requesting the scope is to include the CK into the openid.oauth.scope parameter? That way, you can at approval time make sure that they are requesting a scope that they are actually authorized to pick up. This wouldn't be for security purposes - just as a way to make sure the user experience isn't surprising. Dirk. ___ 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: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
2008/11/13 Allen Tom [EMAIL PROTECTED]: In the registered consumer case, why not just do: openid.assoc_handle=consumer_key openid.mac_key=consumer_secret This implies that the consumer key is HMAC-SHA1. What if it is RSA? ? In the unregistered consumer case, the OpenID association request could be extended to hand out Consumer keys, which are then used as the association handle. The scopes and realm could be passed to the association request as well. Allen Dirk Balfanz wrote: Yes, I can see how that would happen. So how about for OPs who tie scope to Consumer Keys, their openid.oauth.scope syntax would look something like this: openid.oauth.scope=consumer_key:scope1,scope2,scope3 Or, if there is a one-to-one mapping from consumer_key to scope, simply like this: openid.oauth.scope=consumer_key Dirk. On Thu, Nov 13, 2008 at 2:04 PM, Darren Bounds [EMAIL PROTECTED] wrote: Certainly but the consumer context you display to the user is falsely represented based solely on the realm in that circumstance. Sent from a mobile device. On Nov 13, 2008, at 4:58 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom [EMAIL PROTECTED] wrote: Dirk Balfanz wrote: I don't think this is true - I believe the realm is sufficient. Let me try and explain. (We'll assume registered consumers.) On the approval page, we need to identify the consumer. In its current form, the spec basically assumes that you're gonna use the realm for that. You're assuming that a realm has only one CK. A site might have multiple consumer keys, with different scopes attached to them... Actually, I wasn't assuming that. At access token request time, you follow the map from consumer-key to realm (that's the direction you can do, right)? If that's a many-to-one map then this will give you one realm. Then you check whether that's the realm that the request token was issued to. The one thing you're losing is that you can't, at approval time, figure out whether that realm is requesting a scope that they have access to. So a realm could ask for a certain scope in their auth request, the user approves it, and then at access-token-request time, you won't issue the token b/c they're using a CK that doesn't have enough privileges. It's still secure, but gives you a crappy user experience if the consumer mixes up their CKs. Wait - I think I have an idea: what if the Yahoo-specific way of requesting the scope is to include the CK into the openid.oauth.scope parameter? That way, you can at approval time make sure that they are requesting a scope that they are actually authorized to pick up. This wouldn't be for security purposes - just as a way to make sure the user experience isn't surprising. Dirk. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Adding OAuth signature methods, including RSA-SHA1, to OpenID 2.1 is supposed to happen. It is probably not a good idea to return RSA keys via association requests for unregistered consumers though. Allen Breno de Medeiros wrote: 2008/11/13 Allen Tom [EMAIL PROTECTED]: In the registered consumer case, why not just do: openid.assoc_handle=consumer_key openid.mac_key=consumer_secret This implies that the consumer key is HMAC-SHA1. What if it is RSA? ? In the unregistered consumer case, the OpenID association request could be extended to hand out Consumer keys, which are then used as the association handle. The scopes and realm could be passed to the association request as well. Allen Dirk Balfanz wrote: Yes, I can see how that would happen. So how about for OPs who tie scope to Consumer Keys, their openid.oauth.scope syntax would look something like this: openid.oauth.scope=consumer_key:scope1,scope2,scope3 Or, if there is a one-to-one mapping from consumer_key to scope, simply like this: openid.oauth.scope=consumer_key Dirk. On Thu, Nov 13, 2008 at 2:04 PM, Darren Bounds [EMAIL PROTECTED] wrote: Certainly but the consumer context you display to the user is falsely represented based solely on the realm in that circumstance. Sent from a mobile device. On Nov 13, 2008, at 4:58 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom [EMAIL PROTECTED] wrote: Dirk Balfanz wrote: I don't think this is true - I believe the realm is sufficient. Let me try and explain. (We'll assume registered consumers.) On the approval page, we need to identify the consumer. In its current form, the spec basically assumes that you're gonna use the realm for that. You're assuming that a realm has only one CK. A site might have multiple consumer keys, with different scopes attached to them... Actually, I wasn't assuming that. At access token request time, you follow the map from consumer-key to realm (that's the direction you can do, right)? If that's a many-to-one map then this will give you one realm. Then you check whether that's the realm that the request token was issued to. The one thing you're losing is that you can't, at approval time, figure out whether that realm is requesting a scope that they have access to. So a realm could ask for a certain scope in their auth request, the user approves it, and then at access-token-request time, you won't issue the token b/c they're using a CK that doesn't have enough privileges. It's still secure, but gives you a crappy user experience if the consumer mixes up their CKs. Wait - I think I have an idea: what if the Yahoo-specific way of requesting the scope is to include the CK into the openid.oauth.scope parameter? That way, you can at approval time make sure that they are requesting a scope that they are actually authorized to pick up. This wouldn't be for security purposes - just as a way to make sure the user experience isn't surprising. Dirk. ___ 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: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
In the registered consumer case, why not just do: openid.assoc_handle=consumer_key openid.mac_key=consumer_secret ? In the unregistered consumer case, the OpenID association request could be extended to hand out Consumer keys, which are then used as the association handle. The scopes and realm could be passed to the association request as well. Allen Dirk Balfanz wrote: Yes, I can see how that would happen. So how about for OPs who tie scope to Consumer Keys, their openid.oauth.scope syntax would look something like this: openid.oauth.scope=consumer_key:scope1,scope2,scope3 Or, if there is a one-to-one mapping from consumer_key to scope, simply like this: openid.oauth.scope=consumer_key Dirk. On Thu, Nov 13, 2008 at 2:04 PM, Darren Bounds [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Certainly but the consumer context you display to the user is falsely represented based solely on the realm in that circumstance. Sent from a mobile device. On Nov 13, 2008, at 4:58 PM, Dirk Balfanz [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Dirk Balfanz wrote: I don't think this is true - I believe the realm is sufficient. Let me try and explain. (We'll assume registered consumers.) On the approval page, we need to identify the consumer. In its current form, the spec basically assumes that you're gonna use the realm for that. You're assuming that a realm has only one CK. A site might have multiple consumer keys, with different scopes attached to them... Actually, I wasn't assuming that. At access token request time, you follow the map from consumer-key to realm (that's the direction you can do, right)? If that's a many-to-one map then this will give you one realm. Then you check whether that's the realm that the request token was issued to. The one thing you're losing is that you can't, at approval time, figure out whether that realm is requesting a scope that they have access to. So a realm could ask for a certain scope in their auth request, the user approves it, and then at access-token-request time, you won't issue the token b/c they're using a CK that doesn't have enough privileges. It's still secure, but gives you a crappy user experience if the consumer mixes up their CKs. Wait - I think I have an idea: what if the Yahoo-specific way of requesting the scope is to include the CK into the openid.oauth.scope parameter? That way, you can at approval time make sure that they are requesting a scope that they are actually authorized to pick up. This wouldn't be for security purposes - just as a way to make sure the user experience isn't surprising. Dirk. ___ specs mailing list specs@openid.net mailto:specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
On Thu, Nov 13, 2008 at 5:58 PM, Allen Tom [EMAIL PROTECTED] wrote: Adding OAuth signature methods, including RSA-SHA1, to OpenID 2.1 is supposed to happen. It is probably not a good idea to return RSA keys via association requests for unregistered consumers though. Ok, but what is wrong for you to instruct the developers to insert the consumer_key in the scope parameter, and they bind it to the approved request token? Since each OAuth SP has defined scope differently, they will have to look it up what to put in the scope anyway. Allen Breno de Medeiros wrote: 2008/11/13 Allen Tom [EMAIL PROTECTED]: In the registered consumer case, why not just do: openid.assoc_handle=consumer_key openid.mac_key=consumer_secret This implies that the consumer key is HMAC-SHA1. What if it is RSA? ? In the unregistered consumer case, the OpenID association request could be extended to hand out Consumer keys, which are then used as the association handle. The scopes and realm could be passed to the association request as well. Allen Dirk Balfanz wrote: Yes, I can see how that would happen. So how about for OPs who tie scope to Consumer Keys, their openid.oauth.scope syntax would look something like this: openid.oauth.scope=consumer_key:scope1,scope2,scope3 Or, if there is a one-to-one mapping from consumer_key to scope, simply like this: openid.oauth.scope=consumer_key Dirk. On Thu, Nov 13, 2008 at 2:04 PM, Darren Bounds [EMAIL PROTECTED] wrote: Certainly but the consumer context you display to the user is falsely represented based solely on the realm in that circumstance. Sent from a mobile device. On Nov 13, 2008, at 4:58 PM, Dirk Balfanz [EMAIL PROTECTED] wrote: On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom [EMAIL PROTECTED] wrote: Dirk Balfanz wrote: I don't think this is true - I believe the realm is sufficient. Let me try and explain. (We'll assume registered consumers.) On the approval page, we need to identify the consumer. In its current form, the spec basically assumes that you're gonna use the realm for that. You're assuming that a realm has only one CK. A site might have multiple consumer keys, with different scopes attached to them... Actually, I wasn't assuming that. At access token request time, you follow the map from consumer-key to realm (that's the direction you can do, right)? If that's a many-to-one map then this will give you one realm. Then you check whether that's the realm that the request token was issued to. The one thing you're losing is that you can't, at approval time, figure out whether that realm is requesting a scope that they have access to. So a realm could ask for a certain scope in their auth request, the user approves it, and then at access-token-request time, you won't issue the token b/c they're using a CK that doesn't have enough privileges. It's still secure, but gives you a crappy user experience if the consumer mixes up their CKs. Wait - I think I have an idea: what if the Yahoo-specific way of requesting the scope is to include the CK into the openid.oauth.scope parameter? That way, you can at approval time make sure that they are requesting a scope that they are actually authorized to pick up. This wouldn't be for security purposes - just as a way to make sure the user experience isn't surprising. Dirk. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
I changed my mind on this one. A. The fact that scopes are not standardized in OAuth today does not mean that in the future *some* scopes (e.g., related to portable contacts) may be standardized. B. The consumer key is an intrinsic identifier of the party requesting association and probably should be included, with the realm, in the association request (if available). There is no need, however, to include any additional information in the authentication request. The consumer key can be bound to the association handle. On Thu, Nov 13, 2008 at 6:43 PM, Allen Tom [EMAIL PROTECTED] wrote: In the future, we might update our OAuth service to allow developers to pass us the scope dynamically, rather than binding the scope to the CK. However, we'd still probably require developers to agree to a TOS in order to get a CK/CS. I'm concerned about having to tell developers to pass the CK via the scope parameter for the first revision, and then later telling them that scope parameter actually means the scope. I'd like to have one parameter (possibly optional) that means CK, and another parameter (also optional) that means Scope. Overloading a single parameter can get really messy in the long run. Allen Breno de Medeiros wrote: Ok, but what is wrong for you to instruct the developers to insert the consumer_key in the scope parameter, and they bind it to the approved request token? -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
