Subject: [OAUTH-WG] OAuth XRD?

From: "Paul C. Bryan" <[email-masked]>
Date: Wed, 24 Feb 2010 09:30:17 -0800

This is a message directed mostly at Eran:

Is the OAuth 2.0 discovery mechanism still expected to be via a
"provider" attribute in the WWW-Authenticate header, or is host-meta
expected to take over?

Paul

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 24 Feb 2010 19:40:23 -0700

No idea. I am not sure yet what the discovery requirements are. For example, are clients expected to be familiar with each of the token-obtaining profiles and just need a single URI for each supported mechanism? XRD is useful for describing a bunch of links for such endpoints, but it might just be that the discovery information can be provided directly in the header.

Until we know what OAuth 2.0 looks like, we can't really discuss discovery much.

Is there a reason why you are asking now?

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul C. Bryan
> Sent: Wednesday, February 24, 2010 9:30 AM
> To: [email-masked]
> Subject: [OAUTH-WG] OAuth XRD?
> 
> Is the OAuth 2.0 discovery mechanism still expected to be via a "provider"
> attribute in the WWW-Authenticate header, or is host-meta expected to
> take over?
> 
> Paul
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Paul C. Bryan" <[email-masked]>
Date: Wed, 24 Feb 2010 18:58:06 -0800

I've been mostly following the pattern in your XRD-Based OAuth Discovery
Sneak Peek, where a client can discover how to interact with an OAuth
token service in reaction to the OAuth challenge. What got me
second-guessing this was a passing reference to OAuth in the example in
XRD version 1.0.

I'm asking now because in the process of simplifying the UMA spec, I
need to decide on some of the OAuth discovery mechanisms it will use.

Paul

On Wed, 2010-02-24 at 19:40 -0700, Eran Hammer-Lahav wrote:
> No idea. I am not sure yet what the discovery requirements are. For
> example, are clients expected to be familiar with each of the
> token-obtaining profiles and just need a single URI for each supported
> mechanism? XRD is useful for describing a bunch of links for such
> endpoints, but it might just be that the discovery information can be
> provided directly in the header.
> 
> "provider"

---

From: John Panzer <[email-masked]>
Date: Wed, 24 Feb 2010 21:38:48 -0800

Www-Authenticate plus Link headers seem like they would involve
minimal wheel re-invention.

-- 
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 25 Feb 2010 00:26:48 -0700

That's how I feel. In other words, we need to make the protocol configuration simple enough that this is all discovery needs.

EHL

> Of John Panzer
> Sent: Wednesday, February 24, 2010 9:39 PM
> To: Paul C. Bryan
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] OAuth XRD?
> 
> Www-Authenticate plus Link headers seem like they would involve minimal
> wheel re-invention.
> 
> > I've been mostly following the pattern in your XRD-Based OAuth
> > Discovery Sneak Peek, where a client can discover how to interact with
> > an OAuth token service in reaction to the OAuth challenge. What got me
> > second-guessing this was a passing reference to OAuth in the example
> > in XRD version 1.0.
> >
> >> token-obtaining profiles and just need a single URI for each
> >> supported mechanism? XRD is useful for describing a bunch of links
> >> for such endpoints, but it might just be that the discovery
> >> information can be provided directly in the header.
> >>