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
