subject:"OpenID\/Oauth hybrid"

On Mon, Nov 24, 2008 at 10:06 PM, Martin Atkins <[EMAIL PROTECTED]>wrote:

> Dirk Balfanz wrote:
> > I'm not sure I understand what the commotion is about :-)
> >
> > OAuth discovery (when it is done), will answer the question: given the
> > URL of a resource, where do I go to get access tokens for that resource.
> > The question answered by the XRD element described in Section 5 is "does
> > this OpenID endpoint support the Hybrid protocol". These two questions
> > are somewhat related, but clearly different. And, yes, the latter is not
> > nearly as exciting as the former.
> >
>
> What is a consumer intended to do with this information?
>

It could decide to combine an OpenID auth request and an OAuth request into
one hybrid request, instead of doing OpenID first, and then (once the user
is logged in) doing OAuth. This information also tells the consumer where
the auth-request endpoint of the Combined Provider is.

>
> Telling me that the OpenID provider also supports the OAuth hybrid
> protocol is not useful alone. It's not like I can just take any OAuth
>

Agreed.

> token in the world and feed it to this endpoint.
>
> More useful, I think, would be to have the OAuth discovery information
> *at the service endpoint* say that "the OAuth authorization URL for this
>

Agreed.

These are not mutually exclusive. When performing discovery on a
user-supplied identifier it's useful to say "the combined endpoint for this
user-supplied identifier is over there". (We'll also need to be able to say
"the request token you'll get from the combined endpoint can be exchanged
for an access token over here" - but that will be covered in the OAuth
discovery spec.) At the combined endpoint it would indeed make sense to say
where the other OAuth URLs are (although the combined endpoint needs only
one other OAuth URL - the access token endpoint).

> service is , and the combined OpenID/OAuth endpoint for this
> service is ". The first part of this will presumably be
> catered for by OAuth discovery.

Yes.

> The second part seems like it ought to
> be an extension to OAuth discovery, though I don't have a good answer
> for what exactly it'd look like on the wire.
>

The second part is exactly what is defined in Section 5. It's part of OpenID
discovery (not OAuth), b/c the combined endpoint _is_ the OpenID endpoint
(an OpenID endpoint that happens to speak the OAuth extension).

> As currently speced, I'm not sure what problem that section is
> addressing or what value it provides. Perhaps for now it'd be better to
>

We're defining an OpenID extension. Consumer will want to know whether or
not a given endpoint speaks that extension. That's all it's doing - just
like AX or PAPE have a section on discoverability. It also gives consumers a
way to look for the combined OpenID/OAuth endpoint (assuming that one day
we'll have these massive XRD documents advertising all sorts of things -
OAuth request token endpoints, portable contact endpoints, etc.).

Dirk.

> take that part out of the Hybrid Protocol specification and defer that
> problem until it's clearer how OAuth discovery will work in general.
>
>
> ___
> 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 - discovery

2008-11-24 Thread Martin Atkins

Dirk Balfanz wrote:
> I'm not sure I understand what the commotion is about :-)
> 
> OAuth discovery (when it is done), will answer the question: given the 
> URL of a resource, where do I go to get access tokens for that resource. 
> The question answered by the XRD element described in Section 5 is "does 
> this OpenID endpoint support the Hybrid protocol". These two questions 
> are somewhat related, but clearly different. And, yes, the latter is not 
> nearly as exciting as the former.
> 

What is a consumer intended to do with this information?

Telling me that the OpenID provider also supports the OAuth hybrid 
protocol is not useful alone. It's not like I can just take any OAuth 
token in the world and feed it to this endpoint.

More useful, I think, would be to have the OAuth discovery information 
*at the service endpoint* say that "the OAuth authorization URL for this 
service is , and the combined OpenID/OAuth endpoint for this 
service is ". The first part of this will presumably be 
catered for by OAuth discovery. The second part seems like it ought to 
be an extension to OAuth discovery, though I don't have a good answer 
for what exactly it'd look like on the wire.

As currently speced, I'm not sure what problem that section is 
addressing or what value it provides. Perhaps for now it'd be better to 
take that part out of the Hybrid Protocol specification and defer that 
problem until it's clearer how OAuth discovery will work in general.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/OAuth hybrid - discovery

I'm not sure I understand what the commotion is about :-)
OAuth discovery (when it is done), will answer the question: given the URL
of a resource, where do I go to get access tokens for that resource. The
question answered by the XRD element described in Section 5 is "does this
OpenID endpoint support the Hybrid protocol". These two questions are
somewhat related, but clearly different. And, yes, the latter is not nearly
as exciting as the former.

Dirk.

On Mon, Nov 24, 2008 at 6:48 PM, Manger, James H <
[EMAIL PROTECTED]> wrote:

> >> Learning just that an OP supports the hybrid protocol
> >> (without any indication of the associated protected resources)
> >> seems to be of minimal value.
>
> > Yes. However, when OAuth discovery happens (and the standardization
> > effort is under way) it will much more than minimal value.
> > Standardizing OAuth discovery is not in scope for this spec, but
> > standardizing hybrid support indication is.
>
>
> A future "OAuth discovery" could say:
>  "This SP supports the hybrid protocol with this OP http://...";
> In this case section "5 Discovery" in the hybrid spec adds no value because
> the app already knows about the support.
>
> Or a future "OAuth discovery" might not mention OpenID.
> In this case section "5 Discovery" in the hybrid spec barely helps as there
> are no links between OP and SP.
>
> >> James Manger
> >> [EMAIL PROTECTED]
> >> Identity and security team — Chief Technology Office — Telstra
>
>
> ___
> 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 - discovery

2008-11-24 Thread Manger, James H

>> Learning just that an OP supports the hybrid protocol
>> (without any indication of the associated protected resources)
>> seems to be of minimal value.

> Yes. However, when OAuth discovery happens (and the standardization
> effort is under way) it will much more than minimal value.
> Standardizing OAuth discovery is not in scope for this spec, but
> standardizing hybrid support indication is.


A future "OAuth discovery" could say:
 "This SP supports the hybrid protocol with this OP http://...";
In this case section "5 Discovery" in the hybrid spec adds no value because the 
app already knows about the support.

Or a future "OAuth discovery" might not mention OpenID.
In this case section "5 Discovery" in the hybrid spec barely helps as there are 
no links between OP and SP.

>> James Manger
>> [EMAIL PROTECTED]
>> Identity and security team — Chief Technology Office — Telstra


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/OAuth hybrid - discovery

2008-11-24 Thread Breno de Medeiros

On Mon, Nov 24, 2008 at 6:29 PM, Manger, James H
<[EMAIL PROTECTED]> wrote:
> Breno,
>
>> The fact that the OP indicates support for hybrid has nothing to do
>> with directed identity, of whether or not they use the same XRDS file.
>
> What is section "5 Discovery" for?
> Is it supposed to allow an app (after finding a user's OP) to make additional 
> requests to get the OP's metadata to see if it supports the hybrid protocol?
>
> Learning just that an OP supports the hybrid protocol (without any indication 
> of the associated protected resources) seems to be of minimal value.

Yes. However, when OAuth discovery happens (and the standardization
effort is under way) it will much more than minimal value.
Standardizing OAuth discovery is not in scope for this spec, but
standardizing hybrid support indication is.

>
>
> James Manger
> [EMAIL PROTECTED]
> Identity and security team — Chief Technology Office — Telstra
>
>
>
> ___
> 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 - discovery

2008-11-24 Thread Manger, James H

Breno,

> The fact that the OP indicates support for hybrid has nothing to do
> with directed identity, of whether or not they use the same XRDS file.

What is section "5 Discovery" for?
Is it supposed to allow an app (after finding a user's OP) to make additional 
requests to get the OP's metadata to see if it supports the hybrid protocol?

Learning just that an OP supports the hybrid protocol (without any indication 
of the associated protected resources) seems to be of minimal value.


James Manger
[EMAIL PROTECTED]
Identity and security team — Chief Technology Office — Telstra



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/OAuth hybrid - discovery

2008-11-24 Thread Breno de Medeiros

On Mon, Nov 24, 2008 at 5:34 PM, Manger, James H
<[EMAIL PROTECTED]> wrote:
> Section 5 Discovery of the OpenID/OAuth hybrid draft spec says
>  http://specs.openid.net/extensions/oauth/1.0
> should appear in the XRDS discovery document to indicate support for the 
> protocol.
>
>
> This doesn't seem to be the right way around.
>
> Discovery is performed on a user's OpenID identifier. It does not make sense 
> for a user to indicate if an OP supports the hybrid protocol.
> Additionally, support cannot be indicated by users who use an HTML page for 
> their OpenID identifier (with an  
> element).
>
> An OP could indicate that it supports the hybrid protocol in its own XRDS 
> file, assuming all users use directed identity and they all use the same OP 
> XRDS file. I hope we don't have to hardwire these assumptions into the hybrid 
> spec.

The fact that the OP indicates support for hybrid has nothing to do
with directed identity, of whether or not they use the same XRDS file.

> Even in this case, however, indicating hybrid support at the OP is not of 
> much use if the RP/consumer cannot tell which protected resources are covered.
>
> For example, adding the hybrid indicator to the Yahoo OP XRDS file 
> <http://open.login.yahooapis.com/openid20/www.yahoo.com/xrds> does not tell 
> an app if it can use the hybrid protocol to access:
> * Yahoo email address book (probably);
> * Flickr photos (maybe?, it is owned by Yahoo);
> * Microsoft hotmail (perhaps not currently, but a Yahoo/Microsoft merger was 
> discussed earlier this year);
> * Picassa photos (presumably not, as it is owned by Google).
>

This is out of scope for this spec, because OAuth discovery is under
development.

>
> Discovery could work if the metadata for the OAuth Service Provider indicated 
> it supports the hybrid protocol with a specific OP.
>
> [My preferred way to indicate this would be: a request to a protected 
> resource receiving a "401 Unauthenticated" response with a "WWW-Authenticate" 
> HTTP header that included the URL of the OP. If that OP URL matches the OP 
> found from OpenID discovery on the user's OpenID identifier then the app can 
> use the hybrid protocol.]
>
>
>
>
> James Manger
> [EMAIL PROTECTED]
> Identity and security team — Chief Technology Office — Telstra
> ___
> 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

OpenID/OAuth hybrid - discovery

2008-11-24 Thread Manger, James H

Section 5 Discovery of the OpenID/OAuth hybrid draft spec says
  http://specs.openid.net/extensions/oauth/1.0
should appear in the XRDS discovery document to indicate support for the 
protocol.


This doesn't seem to be the right way around.

Discovery is performed on a user's OpenID identifier. It does not make sense 
for a user to indicate if an OP supports the hybrid protocol.
Additionally, support cannot be indicated by users who use an HTML page for 
their OpenID identifier (with an  
element).

An OP could indicate that it supports the hybrid protocol in its own XRDS file, 
assuming all users use directed identity and they all use the same OP XRDS 
file. I hope we don't have to hardwire these assumptions into the hybrid spec.
Even in this case, however, indicating hybrid support at the OP is not of much 
use if the RP/consumer cannot tell which protected resources are covered.

For example, adding the hybrid indicator to the Yahoo OP XRDS file 
<http://open.login.yahooapis.com/openid20/www.yahoo.com/xrds> does not tell an 
app if it can use the hybrid protocol to access:
* Yahoo email address book (probably);
* Flickr photos (maybe?, it is owned by Yahoo);
* Microsoft hotmail (perhaps not currently, but a Yahoo/Microsoft merger was 
discussed earlier this year);
* Picassa photos (presumably not, as it is owned by Google).


Discovery could work if the metadata for the OAuth Service Provider indicated 
it supports the hybrid protocol with a specific OP.

[My preferred way to indicate this would be: a request to a protected resource 
receiving a "401 Unauthenticated" response with a "WWW-Authenticate" HTTP 
header that included the URL of the OP. If that OP URL matches the OP found 
from OpenID discovery on the user's OpenID identifier then the app can use the 
hybrid protocol.]




James Manger
[EMAIL PROTECTED]
Identity and security team — Chief Technology Office — Telstra
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

>
>
> Otherwise, the spec is looking pretty good!
>

Great! We're officially calling it Draft 1 now :-) (the previous version was
Draft 0).

Dirk.


>
> Allen
>
>
> Dirk Balfanz wrote:
>
>>
>> Ok, new version is up. I took out the sentence that recommended to send a
>> cancel. I also added a 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

On Wed, Nov 19, 2008 at 4:03 PM, Manger, James H
<[EMAIL PROTECTED]> wrote:
> Breno,
>
> Thanks for your responses.
>
>> The scopes are needed for the approval page to be rendered.
>> The whole thing is meaningless otherwise
>
> I absolutely agree that the auth/authz redirect needs to know what actions 
> are being authorized, ie the "scope". I don't want to eliminate the scope, 
> just use a single opaque token to represent it -- regardless of which aspects 
> any specific SP needs the scope to encompass [app id, resources, permissions, 
> lifetimes...]. The token comes from a URI, which is what really represents 
> the scope.
>
>> You mean that the app has to understand all of the above,
>> but will use that knowledge during the discovery process,
>> rather than authorization
>
> *Something* has to understand all of the above [scope, permissions, 
> lifetime...] -- but it does not have to be the app.

Sure. That something is able to inform the app what to put in the
scope parameter?

> It can be the app. It can be the user. It can be another system that provides 
> discovery details. Perhaps it can be a hyperlink on a web page.
>
> The app just has a URI and it flows from there.

The scope is an optional element of this spec. If and when we have a
discovery mechanism that makes this obsolete, than it can be safely
left empty. Or discovery could provide what to use as the scope
parameter. At this point, since we do not have discovery, the spec
needs an explicit place to talk about scope.

>
>
>> If that [discovery] effort is successful,
>> I do not think any of these issues are intractable.
>
> It is conceivable that discovery can provide 'scope' strings, and even 
> 'consumer' values for unregistered apps -- but that does not feel like it 
> fits well with the web architecture. It feels unnecessarily complicated and 
> OAuth-specific.
> I can image discovery providing:
>  A URI for my address book;
>  A URI for my calendar;
>  A URI for my photos;
>  A separate URI for my photos of a particular conference;
> I am concerned that with the current hybrid draft, discovery will have to 
> define 'scope' strings etc in addition to a URI to access a service. I doubt 
> generic web discovery mechanisms will
> offer that.

Scope strings? what about just using the above URIs as scopes? Clearly
you need to find already the OpenID+OAuth hybrid endpoint & the URIs
indicating scope. Each of these URIs could also have metadata
associated with them via XRD, e.g., they could define their own scope
strings. Or in the absence of these, the URIs themselves could be used
as scopes. There are many options here. I am not sure all of them
violate the web infrastructure or are OAuth-specific.

Let me pose this problem then: Drop the request token request in the
OAuth spec. Now you have discovery and authorization. What do you
suggest to indicate scope?

>
>
>
> James Manger
> [EMAIL PROTECTED]
> Identity and security team — Chief Technology Office — Telstra
> ___
> 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

2008-11-19 Thread Manger, James H

Breno,

Thanks for your responses.

> The scopes are needed for the approval page to be rendered.
> The whole thing is meaningless otherwise

I absolutely agree that the auth/authz redirect needs to know what actions are 
being authorized, ie the "scope". I don't want to eliminate the scope, just use 
a single opaque token to represent it -- regardless of which aspects any 
specific SP needs the scope to encompass [app id, resources, permissions, 
lifetimes...]. The token comes from a URI, which is what really represents the 
scope.

> You mean that the app has to understand all of the above,
> but will use that knowledge during the discovery process,
> rather than authorization

*Something* has to understand all of the above [scope, permissions, 
lifetime...] -- but it does not have to be the app.
It can be the app. It can be the user. It can be another system that provides 
discovery details. Perhaps it can be a hyperlink on a web page.

The app just has a URI and it flows from there.


> If that [discovery] effort is successful,
> I do not think any of these issues are intractable.

It is conceivable that discovery can provide 'scope' strings, and even 
'consumer' values for unregistered apps -- but that does not feel like it fits 
well with the web architecture. It feels unnecessarily complicated and 
OAuth-specific.
I can image discovery providing:
  A URI for my address book;
  A URI for my calendar;
  A URI for my photos;
  A separate URI for my photos of a particular conference;
I am concerned that with the current hybrid draft, discovery will have to 
define 'scope' strings etc in addition to a URI to access a service. I doubt 
generic web discovery mechanisms will offer that.



James Manger
[EMAIL PROTECTED]
Identity and security team — Chief Technology Office — Telstra
___
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]

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

On Wed, Nov 19, 2008 at 5:19 AM, Manger, James H
<[EMAIL PROTECTED]> wrote:
> How much special knowledge about the OP/SP is an app expected to have to use 
> the OpenID/OAuth hybrid protocol?  [and some performance issues at the end]
>
> A common case might be an app built to enhance one specific service. It is 
> probably realistic to assume such an app is registered with the SP, and has 
> hardwired knowledge about its OAuth URIs, scopes, signing modes etc.
>
> Another case is an app that dynamically learns who a user's OP is (eg from 
> OpenID discovery) and which SP the user uses for the service of interest 
> (perhaps from the same OpenID discovery). The app notices that the OP and SP 
> are the same (how?) and that they support the hybrid protocol (how?). This 
> app understands OpenID, OAuth, hybrid, and the type of service of interest -- 
> but has no special knowledge about this user's specific OP/SP.
>
> The first case may cover many immediate pain points, particularly as OpenID 
> and OAuth are in their infancy. However, a standard would be much more useful 
> for the whole community and in the medium term if it supported the second 
> case as well.

As I mentioned before, we purposefully let discovery outside of this
spec because there is a separate effort to standardize meta-data
discovery vs. XRD. If that effort is successful, I do not think any of
these issues are intractable.

>
> Even if the discovery aspects are not solved immediately, the hybrid protocol 
> should not *preclude* apps without SP-specific knowledge once discovery 
> mechanisms emerge.

It does not talk about discovery at all, exactly for that reason.

>
>
> The current hybrid draft adds openid.oauth.consumer and openid.oauth.scope 
> fields to an OpenID request. The former forces the app to be pre-registered. 
> The latter requires the app to know about the SP's specific scopes.

The scopes are needed for the approval page to be rendered. The whole
thing is meaningless otherwise.

>
> It seems possible that more parameters might be required in future: perhaps 
> permissions (eg read/write), or lifetime (once-off, for 24 hours, forever).
>
> All these parameters seem to tightly couple the app to the SP.

I would say they tightly couple the request with the meaning of the
authorization required.

>
> An alternative is to add one opaque handle to the OpenID request: a request 
> token. To add a new scope, offer a new permission, support a new lifetime, 
> etc an SP can offer a new URI for getting the new request tokens. As far as 
> the app code is concerned it is just a URI, like any other URI. It doesn't 
> necessarily need code that understands permissions, or scopes, or lifetimes 
> etc.

You mean that the app has to understand all of the above, but will use
that knowledge during the discovery process, rather than
authorization. It needs to know what scope to ask. It needs to know
what permission to require. It does not need to know the lifetime the
OP enforces, but that just indicates that it has no place in the
authorization request.

>
>
>
> Breno de Medeiros said the initial OAuth request for a token "adds a 
> (probably unacceptable) redundant server-to-server call for *every* 
> authentication request".
>
> It may be better for performance to omit the request AFTER the redirect, 
> instead of the request BEFORE the redirect.
>
> OAuth involves:
> 1. get request token
> 2. redirect user to do authorization
> 3. swap request token for access token
> 4. do stuff
>
> Step 3 was added to OAuth to support apps that could not launch/redirect-to a 
> browser. Such apps need the user to manually type in a token, which needs to 
> be short to be human-friendly. Step 3 allows a short token to be exchanged 
> for a longer one that can encode lots of state so the service can operate in 
> a stateless (scalable) manner.
> Step 3 was kept for all OAuth apps (not just those that could not 
> launch/redirect a browser) to keep the spec simple.
>
> The hybrid protocol could save a request/response pair by dropping step 3 (or 
> make it optional so apps that cannot launch/redirect-to a browser can use it).
>
>
> The initial request for a request token (step 1) does not have to affect the 
> user experience -- as it can be done in advance. An app could get request 
> tokens in the background and cache them until one is needed for a hybrid 
> auth/authz redirect.
>
>
> Keeping step 1 but omitting step 3 means the access token needs to be 
> returned in the authentication/authorization response. The request token 
> secret can be used instead of getting a new access token secret.
>
> The hybrid spec says [in section 3 Purpose]
>  "For security reasons, the OA

Re: OpenID/Oauth hybrid

On Wed, Nov 19, 2008 at 5:19 AM, Manger, James H
<[EMAIL PROTECTED]> wrote:
> How much special knowledge about the OP/SP is an app expected to have to use 
> the OpenID/OAuth hybrid protocol?  [and some performance issues at the end]
>
> A common case might be an app built to enhance one specific service. It is 
> probably realistic to assume such an app is registered with the SP, and has 
> hardwired knowledge about its OAuth URIs, scopes, signing modes etc.
>
> Another case is an app that dynamically learns who a user's OP is (eg from 
> OpenID discovery) and which SP the user uses for the service of interest 
> (perhaps from the same OpenID discovery). The app notices that the OP and SP 
> are the same (how?) and that they support the hybrid protocol (how?). This 
> app understands OpenID, OAuth, hybrid, and the type of service of interest -- 
> but has no special knowledge about this user's specific OP/SP.
>
> The first case may cover many immediate pain points, particularly as OpenID 
> and OAuth are in their infancy. However, a standard would be much more useful 
> for the whole community and in the medium term if it supported the second 
> case as well.
>
> Even if the discovery aspects are not solved immediately, the hybrid protocol 
> should not *preclude* apps without SP-specific knowledge once discovery 
> mechanisms emerge.
>
>
> The current hybrid draft adds openid.oauth.consumer and openid.oauth.scope 
> fields to an OpenID request. The former forces the app to be pre-registered. 
> The latter requires the app to know about the SP's specific scopes.
>
> It seems possible that more parameters might be required in future: perhaps 
> permissions (eg read/write), or lifetime (once-off, for 24 hours, forever).
>
> All these parameters seem to tightly couple the app to the SP.
>
> An alternative is to add one opaque handle to the OpenID request: a request 
> token. To add a new scope, offer a new permission, support a new lifetime, 
> etc an SP can offer a new URI for getting the new request tokens. As far as 
> the app code is concerned it is just a URI, like any other URI. It doesn't 
> necessarily need code that understands permissions, or scopes, or lifetimes 
> etc.
>
>
>
> Breno de Medeiros said the initial OAuth request for a token "adds a 
> (probably unacceptable) redundant server-to-server call for *every* 
> authentication request".
>
> It may be better for performance to omit the request AFTER the redirect, 
> instead of the request BEFORE the redirect.
>
> OAuth involves:
> 1. get request token
> 2. redirect user to do authorization
> 3. swap request token for access token
> 4. do stuff
>
> Step 3 was added to OAuth to support apps that could not launch/redirect-to a 
> browser. Such apps need the user to manually type in a token, which needs to 
> be short to be human-friendly. Step 3 allows a short token to be exchanged 
> for a longer one that can encode lots of state so the service can operate in 
> a stateless (scalable) manner.
> Step 3 was kept for all OAuth apps (not just those that could not 
> launch/redirect a browser) to keep the spec simple.
>
> The hybrid protocol could save a request/response pair by dropping step 3 (or 
> make it optional so apps that cannot launch/redirect-to a browser can use it).
>
>
> The initial request for a request token (step 1) does not have to affect the 
> user experience -- as it can be done in advance. An app could get request 
> tokens in the background and cache them until one is needed for a hybrid 
> auth/authz redirect.
>
>
> Keeping step 1 but omitting step 3 means the access token needs to be 
> returned in the authentication/authorization response. The request token 
> secret can be used instead of getting a new access token secret.
>
> The hybrid spec says [in section 3 Purpose]
>  "For security reasons, the OAuth access token is not returned in the URL."
> It is not clear what these security reasons are. I suspect they only apply 
> because the hybrid protocol had dropped the token secret from step 1.
>
>
> [It might not even be necessary to perform step 1 for *every* authentication 
> request. If the returned token simply encodes the scope and/or consumer 
> identity, then the service could set a Cache-Control header indicating that 
> the token can be reused for, say, any authentication requests in the next day 
> (I will have to think about any security implications).
> Alternatively define a way for an app to get a batch of request tokens in one 
> go.]

That sounds like an interesting option.

>
>
>
> James Manger
> [EMAIL PROTECTED]
> Identity and security team — Chief Technology Office — Telstra

Re: OpenID/Oauth hybrid

James,

OAuth is typically used _once_ to get a long-term capability to access
user's data.
The hybrid protocol is used *many time* to login the user.

So the step _after_ the authorization will happen infrequently, and it
is not a penalty issue to require. The step _before_ the authorization
(if mandated in the hybrid) must happen _every_time_  because the
RP/consumer does not know who the user is. It is throwaway busywork in
the vast majority of cases.

On Wed, Nov 19, 2008 at 5:19 AM, Manger, James H
<[EMAIL PROTECTED]> wrote:
> How much special knowledge about the OP/SP is an app expected to have to use 
> the OpenID/OAuth hybrid protocol?  [and some performance issues at the end]
>
> A common case might be an app built to enhance one specific service. It is 
> probably realistic to assume such an app is registered with the SP, and has 
> hardwired knowledge about its OAuth URIs, scopes, signing modes etc.
>
> Another case is an app that dynamically learns who a user's OP is (eg from 
> OpenID discovery) and which SP the user uses for the service of interest 
> (perhaps from the same OpenID discovery). The app notices that the OP and SP 
> are the same (how?) and that they support the hybrid protocol (how?). This 
> app understands OpenID, OAuth, hybrid, and the type of service of interest -- 
> but has no special knowledge about this user's specific OP/SP.
>
> The first case may cover many immediate pain points, particularly as OpenID 
> and OAuth are in their infancy. However, a standard would be much more useful 
> for the whole community and in the medium term if it supported the second 
> case as well.
>
> Even if the discovery aspects are not solved immediately, the hybrid protocol 
> should not *preclude* apps without SP-specific knowledge once discovery 
> mechanisms emerge.
>
>
> The current hybrid draft adds openid.oauth.consumer and openid.oauth.scope 
> fields to an OpenID request. The former forces the app to be pre-registered. 
> The latter requires the app to know about the SP's specific scopes.
>
> It seems possible that more parameters might be required in future: perhaps 
> permissions (eg read/write), or lifetime (once-off, for 24 hours, forever).
>
> All these parameters seem to tightly couple the app to the SP.
>
> An alternative is to add one opaque handle to the OpenID request: a request 
> token. To add a new scope, offer a new permission, support a new lifetime, 
> etc an SP can offer a new URI for getting the new request tokens. As far as 
> the app code is concerned it is just a URI, like any other URI. It doesn't 
> necessarily need code that understands permissions, or scopes, or lifetimes 
> etc.
>
>
>
> Breno de Medeiros said the initial OAuth request for a token "adds a 
> (probably unacceptable) redundant server-to-server call for *every* 
> authentication request".
>
> It may be better for performance to omit the request AFTER the redirect, 
> instead of the request BEFORE the redirect.
>
> OAuth involves:
> 1. get request token
> 2. redirect user to do authorization
> 3. swap request token for access token
> 4. do stuff
>
> Step 3 was added to OAuth to support apps that could not launch/redirect-to a 
> browser. Such apps need the user to manually type in a token, which needs to 
> be short to be human-friendly. Step 3 allows a short token to be exchanged 
> for a longer one that can encode lots of state so the service can operate in 
> a stateless (scalable) manner.
> Step 3 was kept for all OAuth apps (not just those that could not 
> launch/redirect a browser) to keep the spec simple.
>
> The hybrid protocol could save a request/response pair by dropping step 3 (or 
> make it optional so apps that cannot launch/redirect-to a browser can use it).
>
>
> The initial request for a request token (step 1) does not have to affect the 
> user experience -- as it can be done in advance. An app could get request 
> tokens in the background and cache them until one is needed for a hybrid 
> auth/authz redirect.
>
>
> Keeping step 1 but omitting step 3 means the access token needs to be 
> returned in the authentication/authorization response. The request token 
> secret can be used instead of getting a new access token secret.
>
> The hybrid spec says [in section 3 Purpose]
>  "For security reasons, the OAuth access token is not returned in the URL."
> It is not clear what these security reasons are. I suspect they only apply 
> because the hybrid protocol had dropped the token secret from step 1.
>
>
> [It might not even be necessary to perform step 1 for *every* authentication 
> request. If the returned token simply encodes the scope and/or consumer 
> identity, then

OpenID/Oauth hybrid

2008-11-19 Thread Manger, James H

How much special knowledge about the OP/SP is an app expected to have to use 
the OpenID/OAuth hybrid protocol?  [and some performance issues at the end]

A common case might be an app built to enhance one specific service. It is 
probably realistic to assume such an app is registered with the SP, and has 
hardwired knowledge about its OAuth URIs, scopes, signing modes etc.

Another case is an app that dynamically learns who a user's OP is (eg from 
OpenID discovery) and which SP the user uses for the service of interest 
(perhaps from the same OpenID discovery). The app notices that the OP and SP 
are the same (how?) and that they support the hybrid protocol (how?). This app 
understands OpenID, OAuth, hybrid, and the type of service of interest -- but 
has no special knowledge about this user's specific OP/SP.

The first case may cover many immediate pain points, particularly as OpenID and 
OAuth are in their infancy. However, a standard would be much more useful for 
the whole community and in the medium term if it supported the second case as 
well.

Even if the discovery aspects are not solved immediately, the hybrid protocol 
should not *preclude* apps without SP-specific knowledge once discovery 
mechanisms emerge.


The current hybrid draft adds openid.oauth.consumer and openid.oauth.scope 
fields to an OpenID request. The former forces the app to be pre-registered. 
The latter requires the app to know about the SP's specific scopes.

It seems possible that more parameters might be required in future: perhaps 
permissions (eg read/write), or lifetime (once-off, for 24 hours, forever).

All these parameters seem to tightly couple the app to the SP.

An alternative is to add one opaque handle to the OpenID request: a request 
token. To add a new scope, offer a new permission, support a new lifetime, etc 
an SP can offer a new URI for getting the new request tokens. As far as the app 
code is concerned it is just a URI, like any other URI. It doesn't necessarily 
need code that understands permissions, or scopes, or lifetimes etc.



Breno de Medeiros said the initial OAuth request for a token "adds a (probably 
unacceptable) redundant server-to-server call for *every* authentication 
request".

It may be better for performance to omit the request AFTER the redirect, 
instead of the request BEFORE the redirect.

OAuth involves:
1. get request token
2. redirect user to do authorization
3. swap request token for access token
4. do stuff

Step 3 was added to OAuth to support apps that could not launch/redirect-to a 
browser. Such apps need the user to manually type in a token, which needs to be 
short to be human-friendly. Step 3 allows a short token to be exchanged for a 
longer one that can encode lots of state so the service can operate in a 
stateless (scalable) manner.
Step 3 was kept for all OAuth apps (not just those that could not 
launch/redirect a browser) to keep the spec simple.

The hybrid protocol could save a request/response pair by dropping step 3 (or 
make it optional so apps that cannot launch/redirect-to a browser can use it).


The initial request for a request token (step 1) does not have to affect the 
user experience -- as it can be done in advance. An app could get request 
tokens in the background and cache them until one is needed for a hybrid 
auth/authz redirect.


Keeping step 1 but omitting step 3 means the access token needs to be returned 
in the authentication/authorization response. The request token secret can be 
used instead of getting a new access token secret.

The hybrid spec says [in section 3 Purpose]
  "For security reasons, the OAuth access token is not returned in the URL."
It is not clear what these security reasons are. I suspect they only apply 
because the hybrid protocol had dropped the token secret from step 1.


[It might not even be necessary to perform step 1 for *every* authentication 
request. If the returned token simply encodes the scope and/or consumer 
identity, then the service could set a Cache-Control header indicating that the 
token can be reused for, say, any authentication requests in the next day (I 
will have to think about any security implications).
Alternatively define a way for an app to get a batch of request tokens in one 
go.]



James Manger
[EMAIL PROTECTED]
Identity and security team — Chief Technology Office — Telstra
___
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.html>
>> http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.htmlto
>>  address the issues that were raised. Especially, optimizing on how OAuth
>> request token is handled, allowed to remove one full roundtrip!
>> Would appreciate any feedback on the updated suggestion.
>>
>> Thanks
>>
>> On Mon, Nov 3, 2008 at 12:00 PM, < <[EMAIL PROTECTED]>
>> [EMAIL PROTECTED]> wrote:
>>
>>> Send specs mailing list submissions to
>>> specs@openid.net
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> <http://openid.net/mailman/listinfo/specs>
>>> http://openid.net/mailman/listinfo/specs
>>> or, via email, send a message with subject or body 'help' to
>>> <[EMAIL PROTECTED]>[EMAIL PROTECTED]
>>>
>>> You can reach the person managing the list at
>>> <[EMAIL PROTECTED]>[EMAIL PROTECTED]
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of specs digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>   1. Proposal to create the OpenID OAuth Hybrid Working Group
>>>  (Yariv Adan)
>>&g

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 Open

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

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