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
