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...@xmlgrrl.com>
> To: William Mills <wmi...@yahoo-inc.com>
> Cc: Goix Laurent Walter <laurentwalter.g...@telecomitalia.it>; Peter 
> Saint-Andre <stpe...@stpeter.im>; O Auth WG <oauth@ietf.org>; Apps Discuss 
> <apps-disc...@ietf.org>
> 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 <laurentwalter.g...@telecomitalia.it>
>>>  To: Peter Saint-Andre <stpe...@stpeter.im>; William Mills 
> <wmi...@yahoo-inc.com>
>>>  Cc: O Auth WG <oauth@ietf.org>; Apps Discuss 
> <apps-disc...@ietf.org>
>>>  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: apps-discuss-boun...@ietf.org 
> [mailto:apps-discuss-boun...@ietf.org] 
>>>  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
>>>>  apps-disc...@ietf.org
>>>>  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
>>  OAuth@ietf.org
>>  https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> 
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                        http://www.twitter.com/xmlgrrl
> 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to