Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

Martin Atkins wrote: > There's also the need to have something to point at as what the user > trusted, so that other applications can't piggy-back off the trust of a > popular app. > > Hi Martin, The OAuth access token is the credential that is issued to the instance of the application that

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

Allen Tom wrote: > Hi Martin, > > The intent is to be able to identify applications which were not > deliberately designed to be malicious. Well designed malicious apps > would piggy back off of another app's CK or just cycle through a list of > CKs to evade detection. > > However, there have

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

Hi Martin, The intent is to be able to identify applications which were not deliberately designed to be malicious. Well designed malicious apps would piggy back off of another app's CK or just cycle through a list of CKs to evade detection. However, there have been occasions where legitimate a

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-regist

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 ti

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 c

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 s

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] > 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

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 c

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.

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

> > > Otherwise, the spec is looking pretty good! > Great! We're officially calling it Draft 1 now :-) (the previous version was Draft 0). Dirk. > > Allen > > > Dirk Balfanz wrote: > >> >> Ok, new version is up. I took out the sentence that recommended to send a >> cancel. I also added a sectio

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

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 us

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" shoud

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 refle

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 allo

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

Thanks! Fixed. Dirk. On Thu, Nov 20, 2008 at 6:37 AM, Paul Madsen <[EMAIL PROTECTED]> wrote: > 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.c

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:

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 authentic

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

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 portio

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

There is definitely a benefit to not having to roll a new implementation of key authorization for each provider. I'm not saying that OAuth serves no purpose at all. I'm just saying that requiring a business relationship to exist between every consumer and every service provider is not conduciv

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

Hi Martin, Not sure why you say that requiring pre-registration and having an open stack are mutually exclusive. Are you saying that there's no benefit for service providers to provide a standard interface to developers? Allen Martin Atkins wrote: > Allen Tom wrote: >> >> One problem with th

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

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

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 ma

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 OpenI

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 ne

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 au

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

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

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. Wo

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

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 h

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" hea

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 para

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

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 p

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

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 e

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 poin

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

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 >

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: > >> Sadl

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

On Mon, Nov 17, 2008 at 7:53 PM, Manger, James H <[EMAIL PROTECTED]> wrote: > 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 o

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 intera

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 fet

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

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

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 cons

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.scop

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 shoul

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

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

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 f

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 registere

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 associati

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 real

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: open

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]> w

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 o

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 curr

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 consu

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 t

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 t