Subject: [OAUTH-WG] OAuth discovery registration.

From: William Mills <[email-masked]>
Date: Wed, 13 Jun 2012 08:27:36 -0700 (PDT)

Since for the OAUTH SASL mechanism I need discovery for clients to work, and I had to rip the in-band discovery out of that mechanism, and I need it defined somewhere, I've drafted a small doc for the registration of link relation types for OAuth.  It's too late in the process to get this into the core OAuth 2 spec, and it doesn't really fit in the WebFinger. Submission info provided below.

-bill

----------------------------------------------------

A new version of I-D, draft-wmills-oauth-lrdd-00.txt
has been successfully submitted by William Mills and posted to the
IETF repository.

Filename:    draft-wmills-oauth-lrdd
Revision:    00
Title:        LRDD Registry for OAuth 2
Creation date:    2012-06-13
WG ID:        Individual Submission
Number of pages: 10
URL:            http://www.ietf.org/internet-drafts/draft-wmills-oauth-lrdd-00.txt
Status:          http://datatracker.ietf.org/doc/draft-wmills-oauth-lrdd
Htmlized:        http://tools.ietf.org/html/submission.filename }}-00

Abstract:
  Defines link type registrations for the OAuth 2 authentication
  framework.

The IETF Secretariat

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 13 Jun 2012 09:48:22 -0600

On 6/13/12 9:27 AM, William Mills wrote:
> 
> Since for the OAUTH SASL mechanism I need discovery for clients to
> work, and I had to rip the in-band discovery out of that mechanism,
> and I need it defined somewhere, I've drafted a small doc for the
> registration of link relation types for OAuth.  It's too late in the
> process to get this into the core OAuth 2 spec, and it doesn't really
> fit in the WebFinger. Submission info provided below.

Hi Bill, overall this looks good. A few nits:

OLD
   This document defines the LRDD [RFC5988] link type registrations for
   the OAuth [I-D.ietf-oauth-v2] authentication framework.  These link
   types are used during the endpoint discovery process using Web Host
   Metadata [I-D.hammer-hostmeta] and Webfinger
   [I-D.jones-appsawg-webfinger] by clients needing to discover the
   authentication endpoints for a service or site.  It additionally
   defines link type registrations for OAuth 1.0a [RFC5849].

NEW
   This document defines the Link-based Resource Descriptor
   Documents (LRDD) [RFC6415] link type registrations for the
   OAuth [I-D.ietf-oauth-v2] authorization framework.  These link
   types are used during the endpoint discovery process using Web
   Host Metadata [RFC6415] and Webfinger
   [I-D.jones-appsawg-webfinger] by clients needing to discover the
   authorization, token, and access token endpoints for an OAuth2
   service or site.  It additionally defines link type registrations for
OAuth
   1.0a [RFC5849] request initiation endpoints, authorization endpoints,
   and token endpoints.

In Section 4.1.1, you register an "OAuth 2 Authentication Endpoint",
however draft-ietf-oauth-v2 defines only an authorization endpoint, a
token endpoint, and an access token endpoint. Whence this
"authentication endpoint"? Is it just a typo?

Also, is the lack of a link type for OAuth2 access token endpoints an
oversight? It seems so.

You have "Reference: [[this document]]" but I think you want:

Reference: draft-ietf-oauth-v2

and

Reference: RFC 5849

You can remove the reference for draft-hammer-hostmeta (RFC 6415 has
what you need).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Eran Hammer <[email-masked]>
Date: Wed, 13 Jun 2012 16:03:45 +0000

These are straight link relation registrations, not LRDD (which has no registration process). It is helpful to put these registrations in context and use LRDD/host-meta as an example of their use, but the actual registration request is simply for a link relation and nothing else.

EH

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of William Mills
> Sent: Wednesday, June 13, 2012 8:28 AM
> To: O Auth WG; Apps Discuss
> Subject: [OAUTH-WG] OAuth discovery registration.
> 
> 
> 
> Since for the OAUTH SASL mechanism I need discovery for clients to work,
> and I had to rip the in-band discovery out of that mechanism, and I need it
> defined somewhere, I've drafted a small doc for the registration of link
> relation types for OAuth.  It's too late in the process to get this into the core
> OAuth 2 spec, and it doesn't really fit in the WebFinger. Submission info
> provided below.
> 
> -bill
> 
> A new version of I-D, draft-wmills-oauth-lrdd-00.txt has been successfully
> submitted by William Mills and posted to the IETF repository.
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 13 Jun 2012 10:08:07 -0600

On 6/13/12 10:03 AM, Eran Hammer wrote:
> These are straight link relation registrations, not LRDD (which has no registration process). 

Right you are!

/psa

---

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 13 Jun 2012 18:44:19 +0200

Thank you William for this initiative.

I had similar concerns than Peter on authn vs authz.

Under section 4.1.1 I would suggest to use "oauth2-authorize" instead of "oauth2-authenticator", to be consistent with the "oauth2-token" pattern and with the concepts of the oauth2 draft.

The header of the pages still reference sasl/gss-api and would need to be updated.

Also, an example and/or use case section could be beneficial, e.g. to describe its usage in an xrd document. Other use cases may be mentioned as well probably.

I have also noticed that your draft is mentioned as "informational". It is indeed your target or only a typo?

Thanks
walter

> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Per
> conto di Peter Saint-Andre
> Inviato: mercoledì 13 giugno 2012 17.48
> A: William Mills
> Cc: O Auth WG; Apps Discuss
> Oggetto: Re: [apps-discuss] [OAUTH-WG] OAuth discovery registration.
>
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: William Mills <[email-masked]>
Date: Wed, 13 Jun 2012 11:19:54 -0700 (PDT)

On the informational status, that seemed right, but I honestly don't know what the correct choice is here.   The actual registration happens via e-mail I believe, not via this document.

Thanks for the feedback!

-bill

----- Original Message -----
> From: Goix Laurent Walter <[email-masked]>
> To: Peter Saint-Andre <[email-masked]>; William Mills <[email-masked]>
> Cc: O Auth WG <[email-masked]>; Apps Discuss <[email-masked]>
> Sent: Wednesday, June 13, 2012 9:44 AM
> Subject: R: [apps-discuss] [OAUTH-WG] OAuth discovery registration.
> 
>T hank you William for this initiative.
> 
> Under section 4.1.1 I would suggest to use "oauth2-authorize" instead 
> of "oauth2-authenticator", to be consistent with the 
> "oauth2-token" pattern and with the concepts of the oauth2 draft.
> 
> Also, an example and/or use case section could be beneficial, e.g. to describe 
> its usage in an xrd document. Other use cases may be mentioned as well probably.
> 
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone 
> indicate. La diffusione, copia o qualsiasi altra azione derivante dalla 
> conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate 
> ricevuto questo documento per errore siete cortesemente pregati di darne 
> immediata comunicazione al mittente e di provvedere alla sua distruzione, 
> Grazie.
> 
> This e-mail and any attachments is confidential and may contain privileged 
> information intended for the addressee(s) only. Dissemination, copying, printing 
> or use by anybody else is unauthorised. If you are not the intended recipient, 
> please delete this message and any attachments and advise the sender by return 
> e-mail, Thanks.
>

---

From: Eran Hammer <[email-masked]>
Date: Wed, 13 Jun 2012 18:34:59 +0000

The registration is a simple process. You write a draft and get the designated expert to review. They can decide to wait until the document is published/approved or if they think it is likely to be approved, get the registration request published earlier. They can also reject it with a reason.

I would encourage you to contact the link registry list and ask for feedback before making the official request which you can do once the draft is stable.

EH

> Sent: Wednesday, June 13, 2012 11:20 AM
> To: Goix Laurent Walter; Peter Saint-Andre
> Subject: Re: [OAUTH-WG] R: [apps-discuss] OAuth discovery registration.
> 
> On the informational status, that seemed right, but I honestly don't know
> what the correct choice is here.   The actual registration happens via e-mail I
> believe, not via this document.
> 
> Thanks for the feedback!
> 
> -bill
> 
> 
> 
> > of "oauth2-authenticator", to be consistent with the "oauth2-token"
> > pattern and with the concepts of the oauth2 draft.
> >
> > Also, an example and/or use case section could be beneficial, e.g. to
> > describe its usage in an xrd document. Other use cases may be mentioned
> as well probably.
> >
> >>  Da: [email-masked]
> >> [mailto:[email-masked]]
> > Per
> >> Host
> >>     service or site.  It additionally defines link type registrations
> >> for  OAuth
> >>  however draft-ietf-oauth-v2 defines only an authorization endpoint,
> >> a  token endpoint, and an access token endpoint. Whence this
> >>  Also, is the lack of a link type for OAuth2 access token endpoints
> >> an  oversight? It seems so.
> >>
> > Questo messaggio e i suoi allegati sono indirizzati esclusivamente
> > alle persone indicate. La diffusione, copia o qualsiasi altra azione
> > derivante dalla conoscenza di queste informazioni sono rigorosamente
> > vietate. Qualora abbiate ricevuto questo documento per errore siete
> > cortesemente pregati di darne immediata comunicazione al mittente e di
> > provvedere alla sua distruzione, Grazie.
> >
> > This e-mail and any attachments is confidential and may contain
> > privileged information intended for the addressee(s) only.
> > Dissemination, copying, printing or use by anybody else is
> > unauthorised. If you are not the intended recipient, please delete
> > this message and any attachments and advise the sender by return e-mail,
> Thanks.
> >

---

From: William Mills <[email-masked]>
Date: Wed, 13 Jun 2012 11:39:05 -0700 (PDT)

Worthwhile to change the document title?

Examples are easy, can do.

----- Original Message -----
> From: Eran Hammer <[email-masked]>
> To: William Mills <[email-masked]>; O Auth WG <[email-masked]>; Apps Discuss <[email-masked]>
> Cc: 
> Sent: Wednesday, June 13, 2012 9:03 AM
> Subject: RE: [OAUTH-WG] OAuth discovery registration.
> 
>T hese are straight link relation registrations, not LRDD (which has no 
> registration process). It is helpful to put these registrations in context and 
> use LRDD/host-meta as an example of their use, but the actual registration 
> request is simply for a link relation and nothing else.
> 
> EH
> 
>>  URL:          
>   http://www.ietf.org/internet-drafts/draft-wmills-oauth-lrdd-
>>  00.txt

---

From: Eve Maler <[email-masked]>
Date: Wed, 13 Jun 2012 11:38:59 -0700

Hi Bill-- In incorporating OAuth into several of the UMA flows, we found a need for the authorization server to provide OAuth-related metadata along with UMA-specific metadata. Originally it was strictly XRD- and hostmeta-based, but now uses a JSON format and is more akin to OpenID Connect's metadata in style: 

http://docs.kantarainitiative.org/uma/draft-uma-core.html#am-endpoints

Do you feel that this new draft is something that ultimately *should* replace the OAuth-specific parts of the metadata we've spec'd out for our use case? Note that we went beyond just the two endpoints, also covering a feature toggle for "dynamic_client_registration_supported" and lists of "oauth_token_profiles_supported" and "oauth_grant_types_supported". The purpose in doing this was to provide a machine-readable mechanism for aiding OAuth-level interop.

Thanks,

	Eve

>> please delete this message and any attachments and advise the sender by return 

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: Eran Hammer <[email-masked]>
Date: Wed, 13 Jun 2012 18:47:02 +0000

Probably, unless you focus the document on using these with host-meta. Also, LRDD is itself just a link relation type so using that instead of host-meta is probably more confusing than helpful. I would just register the link relations to be used with future OAuth discovery via links and give host-meta as one example, and maybe Link headers in a 401 response as another example.

EH

> From: William Mills [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2012 11:39 AM
> To: Eran Hammer; O Auth WG; Apps Discuss
> Subject: Re: [OAUTH-WG] OAuth discovery registration.
> 
> >registration process). It is helpful to put these registrations in
> >context and  use LRDD/host-meta as an example of their use, but the
> >actual registration  request is simply for a link relation and nothing else.
> >
> > EH
> >
> >>  From: [email-masked] [mailto:[email-masked]] On
> >> Behalf  Of William Mills
> >> registration of
> > link
> >>  A new version of I-D, draft-wmills-oauth-lrdd-00.txt has been
> >> successfully  submitted by William Mills and posted to the IETF repository.
> >>
> >>  Title:        LRDD Registry for OAuth 2  Creation date:
> >> 2012-06-13  WG ID:        Individual Submission  Number of pages: 10
> >>  URL:
> >>  Status:
> >> http://datatracker.ietf.org/doc/draft-wmills-oauth-lrdd

---

From: William Mills <[email-masked]>
Date: Wed, 13 Jun 2012 11:59:05 -0700 (PDT)

We certainly overlap, the thing you have that is not in the link type registrations is dynamic_client_registration_supported.  We should be consistent in naming, and ideally the OAuth related JSON elements from a JSON format Webfinger request and your UMA stuff shoudl be identical.  My concern with using a JSON list structure for capability lists is how it would play in the LINK header itself, that seems a bit hairy to put a JSON list inside a quoted application data value.

Do we want something like a "capabilities" list which could include dynamic_client_registration_supported and perhaps others?

-bill

----- Original Message -----
> From: Eve Maler <[email-masked]>
> To: William Mills <[email-masked]>
> Cc: Goix Laurent Walter <[email-masked]>; Peter Saint-Andre <[email-masked]>; O Auth WG <[email-masked]>; Apps Discuss <[email-masked]>
> Sent: Wednesday, June 13, 2012 11:38 AM
> Subject: Re: [OAUTH-WG] [apps-discuss]  OAuth discovery registration.
> 
> Hi Bill-- In incorporating OAuth into several of the UMA flows, we found a need 
> for the authorization server to provide OAuth-related metadata along with 
> UMA-specific metadata. Originally it was strictly XRD- and hostmeta-based, but 
> now uses a JSON format and is more akin to OpenID Connect's metadata in 
> style: 
> 
> Do you feel that this new draft is something that ultimately *should* replace 
> the OAuth-specific parts of the metadata we've spec'd out for our use 
> case? Note that we went beyond just the two endpoints, also covering a feature 
> toggle for "dynamic_client_registration_supported" and lists of 
> "oauth_token_profiles_supported" and 
> "oauth_grant_types_supported". The purpose in doing this was to 
> provide a machine-readable mechanism for aiding OAuth-level interop.
> 
> Thanks,
> 
>     Eve
> 
>>  On the informational status, that seemed right, but I honestly don't 
> know what the correct choice is here.   The actual registration happens via 
> e-mail I believe, not via this document.
>> 
>>  Thanks for the feedback!
>> 
>>  -bill
>> 
>> 
>> 
>>>  The header of the pages still reference sasl/gss-api and would need to 
> be 
>>>  updated.
>>> 
> describe 
>>>  I have also noticed that your draft is mentioned as 
> "informational". 
>>>  It is indeed your target or only a typo?
>>> 
>>>  Thanks
>>>  walter
>>> 
>>>>>  registration of link relation types for OAuth.  It's too 
> late in 
>>>  the
>>>>>  process to get this into the core OAuth 2 spec, and it 
> doesn't 
>>>  really
> a
> privileged

---

From: William Mills <[email-masked]>
Date: Wed, 13 Jun 2012 13:05:10 -0700 (PDT)

I've incorporated a number of changes and added examples.  Thanks to all for the feedback.  I can do a new draft any time if that's useful.

-bill

----- Original Message -----
> From: Peter Saint-Andre <[email-masked]>
> Sent: Wednesday, June 13, 2012 8:48 AM

---

From: Eve Maler <[email-masked]>
Date: Thu, 14 Jun 2012 11:16:42 -0700

FWIW, the reason we ultimately went with JSON was that it removed stumbling blocks around implementation and sheer spec volume. When we used straight XRD, we found that we had to put a full worked example in an appendix so it didn't impede the flow of the spec, and implementers reported to us that JSON would have been much preferable for producing and consuming the config data. When we found the OpenID Connect example, it was a natural fit and so we copied it.

(Not trying to open up past "JRD" discussions, just sharing our experience... If OAuth ultimately absorbs some XRD-formatted hunk of machine-discoverable config data, we'll leverage it.)

	Eve

---

From: William Mills <[email-masked]>
Date: Thu, 14 Jun 2012 14:38:00 -0700 (PDT)

Updated for examples, the editorial issues like replacing link header for lrdd where it appears, fixing authenticate->authorize.

Thanks for the feedback so far.

-bill

------------------

A new version of I-D, draft-wmills-oauth-lrdd-01.txt
has been successfully submitted by William Mills and posted to the
IETF repository.

Filename:    draft-wmills-oauth-lrdd
Revision:    01
Title:        Link Type Registry for OAuth 2
Creation date:    2012-06-14
WG ID:        Individual Submission
Number of pages: 11
URL:            http://www.ietf.org/internet-drafts/draft-wmills-oauth-lrdd-01.txt
Status:          http://datatracker.ietf.org/doc/draft-wmills-oauth-lrdd
Htmlized:        http://tools.ietf.org/html/draft-wmills-oauth-lrdd-01
Diff:            http://tools.ietf.org/rfcdiff?url2=draft-wmills-oauth-lrdd-01

Abstract:

The IETF Secretariat