Re: [OAUTH-WG] [apps-discuss] OAuth discovery registration.

[Eve Maler <[e-mail]>]

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

On 13 Jun 2012, at 11:59 AM, William Mills wrote:

> 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 <[e-mail]>
>> To: William Mills <[e-mail]>
>> Cc: Goix Laurent Walter <[e-mail]>; Peter Saint-Andre <[e-mail]>; O Auth WG <[e-mail]>; Apps Discuss <[e-mail]>
>> 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: 
>> 
>> 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
>> 
>> On 13 Jun 2012, at 11:19 AM, William Mills wrote:
>> 
>>> 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 <[e-mail]>
>>>> To: Peter Saint-Andre <[e-mail]>; William Mills 
>> <[e-mail]>
>>>> Cc: O Auth WG <[e-mail]>; Apps Discuss 
>> <[e-mail]>
>>>> Sent: Wednesday, June 13, 2012 9:44 AM
>>>> Subject: R: [apps-discuss] [OAUTH-WG] OAuth discovery registration.
>>>> 
>>>> T hank 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: [e-mail] 
>> [mailto:[e-mail]] 
>>>> 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.
>>>>> 
>>>>> 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/
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> apps-discuss mailing list
>>>>> [e-mail]
>>>>> 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.
>>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>> 
>> 
>> Eve Maler                                  http://www.xmlgrrl.com/blog
>> [phone]                        http://www.twitter.com/xmlgrrl
>> 
> 


Eve Maler                                  http://www.xmlgrrl.com/blog
[phone]                         http://www.twitter.com/xmlgrrl