subject:"\"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 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]

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]

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]

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]

2008-11-21 Thread Allen Tom

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]

2008-11-21 Thread Allen Tom

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]

2008-11-20 Thread Dirk Balfanz

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.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 [EMAIL PROTECTED]://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
>
>
>
> --
> [image: ConnectID] 
>
<>___
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-20 Thread Paul Madsen

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]

2008-11-19 Thread Dirk Balfanz

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]

2008-11-19 Thread Allen Tom

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.


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]

2008-11-19 Thread Martin Atkins

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 conducive to creating 
an open marketplace where anyone can be a consumer and anyone can be a 
provider as we see with OpenID, and it can't scale beyond a few providers.

So while code reuse is a good thing, I'd like to think we can achieve 
more than that.

Allen Tom wrote:
> 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 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]

2008-11-19 Thread Allen Tom

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

2008-11-19 Thread Dirk Balfanz

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]

2008-11-19 Thread Breno de Medeiros

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

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.

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

Dirk.


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

2008-11-18 Thread Martin Atkins

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?

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

2008-11-18 Thread Martin Atkins

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]

2008-11-18 Thread Allen Tom

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]

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]

2008-11-18 Thread Allen Tom

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]

2008-11-18 Thread Allen Tom

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]

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]

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]

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]

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]

2008-11-17 Thread Breno de Medeiros

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 or scope into the 
> request token when issuing it if they need those details when interacting 
> with the user.
>

That is how we started, but it adds a (probably unacceptable)
redundant server-to-server call for *every* authentication request. We
have decided to abandon this option after much debate. The request
token request is not needed for security reasons because (1) the
return_to URL is mandatory (hybrid only makes sense for web apps) and
(2) The OP/SP signs the response (unlike plain OAuth).

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



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

2008-11-17 Thread Manger, James H

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]

2008-11-17 Thread Dirk Balfanz

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

2008-11-17 Thread Allen Tom

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]

2008-11-17 Thread Dirk Balfanz

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

2008-11-17 Thread Allen Tom

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]

2008-11-16 Thread Dirk Balfanz

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

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

2008-11-13 Thread Breno de Medeiros

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

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

___
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 Thread Breno de Medeiros

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]

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]

2008-11-13 Thread Breno de Medeiros

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]

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

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 Thread Darren Bounds

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]

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.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.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]>[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.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/ > this note proposes
>>> the
>>> formation of a new working group chartered to produce an Open

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]

2008-11-13 Thread Darren Bounds

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 req

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]

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.

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