Also in openID 2 there was an association endpoint that is similar where the client got its secret. Mostly the term is a carryover from that.
I don't have any real objection to changing it to registration to align better with OAuth terminology in the IETF version. John B. On 2012-11-05, at 5:50 PM, "Richer, Justin P." <jric...@mitre.org> wrote: > I thought of this during the merge process as well -- "associate" is a direct > import from OIDC. The reasoning behind this verb is that you're "associating" > a set of client metadata to a particular client identifier. > > I'd be happy to change this term to "client_register" if there's consensus > for a move to that terminology. > > Also, forgot to mention this before: The latest version of it will always be > on my github: > > https://github.com/jricher/oauth-spec > > This has the added benefit of allowing you all to fork the repo, make edits, > file issues, and make pull requests against the document in between uploads > to the IETF datatracker. > > -- Justin > > > On Nov 5, 2012, at 5:38 PM, Tim Bray wrote: > >> Quick question: Why is it “association request”, not “registration request”? >> Nearly everywhere the term “association” appears, it seems like you could >> insert “registration” and achieve better clarity. -T >> >> On Mon, Nov 5, 2012 at 2:20 PM, Richer, Justin P. <jric...@mitre.org> wrote: >> This draft combines the best-usable parts UMA and OpenID Connect dynamic >> registration drafts into one document that's designed to facilitate dynamic >> client registration. I've significantly reorganized the document and I've >> tried to exorcise any obvious dependencies on OpenID Connect or UMA. This >> protocol follows the OpenID Connect registration model most closely, in that >> it's form-parameters in and JSON out (as opposed to JSON round trip). This >> matches the rest of the OAuth protocol. It's a push model only for metadata >> as well, but it allows clients to push updates. >> >> General formatting is still rough, but I think that the text is mostly >> readable and complete. There are several Editor's Notes in the document that >> bring up what I consider to be open questions or issues with the >> functionality. One that I forgot to leave a note for is client >> unregistration. Does it make sense to provide mechanisms for a full >> lifecycle for well-behaved clients? >> >> We'll be discussing this draft in person at the IETF meeting for the OAuth >> working group on Thursday for anybody who wants to throw tomatoes at me*. >> >> -- Justin >> >> >> *Please do not actually throw tomatoes at me. >> >> ________________________________________ >> From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] on behalf of >> internet-dra...@ietf.org [internet-dra...@ietf.org] >> Sent: Monday, November 05, 2012 5:12 PM >> To: i-d-annou...@ietf.org >> Cc: oauth@ietf.org >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol Working Group >> of the IETF. >> >> Title : OAuth Dynamic Client Registration Protocol >> Author(s) : Justin Richer >> Thomas Hardjono >> Maciej Machulak >> Eve Maler >> Christian Scholz >> Nat Sakimura >> John Bradley >> Michael B. Jones >> Filename : draft-ietf-oauth-dyn-reg-01.txt >> Pages : 20 >> Date : 2012-11-05 >> >> Abstract: >> This specification proposes an OAuth Dynamic Client Registration >> protocol. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-01 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > Openid-specs-ab mailing list > openid-specs...@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
