Re: OpenID/OAuth hybrid - discovery

[Martin Atkins]

Dirk Balfanz wrote:
> 
> 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.).
> 

I guess I'm assuming that the OAuth service saying "use that OpenID 
provider for hybrid OpenID/OAuth" implies that the OpenID Provider 
supports the extension.

However, I guess the following flow could arise:
  * User does something that requires OAuth.
  * Consumer does OAuth Discovery (to be defined) and determines, 
amongst other things, the URL of the OpenID Provider that will do the 
combined OpenID/OAuth bit.
  * Consumer does discovery on the OpenID Provider and determines that 
it doesn't actually support the extension.
  * Consumer falls back on the non-combined flow, or just tells the user 
that the service provider is broken.

While it's nice to fail early in this case, the consumer still needs to 
deal with a bunch of post-authorization failure cases:
  * Provider claimed to support the extension but didn't actually return 
anything.
  * Provider claimed to support the extension but the approved request 
token doesn't actually work for some reason.
  * Provider claimed to support the extension but it turns out it 
doesn't support this particular sort of request token.
  * ...

In most cases, the implication from the OAuth discovery step will be 
enough and everything will work out. I'm not sure whether failing early 
in this one (unlikely) error case is worth the extra HTTP transaction(s) 
to find out whether the provider really supports the extension. It'd be 
more efficient to just send a request to the OpenID provider with the 
extension arguments and see if you get back a response.

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

Re: OpenID/OAuth hybrid - discovery

[Dirk Balfanz]

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

[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

[Dirk Balfanz]

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

[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

[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

[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

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

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

[Dirk Balfanz]

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

[Dirk Balfanz]

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]

[Dirk Balfanz]

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]

[Dirk Balfanz]

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