help
On November 8, 2012 12:00:32 PM PST, [email protected] wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/oauth > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send OAuth mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. bag-of-keys metadata UC for the "mac" discussion (Leif Johansson) > 2. Re: [Openid-specs-ab] I-D Action: > draft-ietf-oauth-dyn-reg-01.txt (John Bradley) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 08 Nov 2012 17:01:58 +0100 > From: Leif Johansson <[email protected]> > To: [email protected] > Subject: [OAUTH-WG] bag-of-keys metadata UC for the "mac" discussion > Message-ID: <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > I promised to send a UC to the list as input to the discussion around new > token formats. > > --- > > Several large-scale deployments of public-key use a "bag-of-keys" model > for key management: you stick endpoint information together with public > keys for those endpoints in a signable container which is then signed with > a private key associated with some "trust provider" an distributed to all > entities/relying parties. > > Examples include various trust status lists formats and things like SAML > metadata. > > The latter case (SAML metadata) isn't necessarily tied to the SAML v2 > _protocol_ but it is used for that. Large-scale SAML federations are often > setup to depend on distribution of signed SAML metadata. > > Consider the case when a large number of relying parties of such a SAML > federation are also either OAUTH2 resource or authorization servers. Today > all of those OAUTH2 entities have to be provisioned with separate client > secrets that have no relationship to the trust infrastructure already in use > in the federation. > > It is not uncommon for such federations to have 1000s and sometimes > 10000s of entities making client secret management something of a > scalability issue. > > Even with dynreg the problem of managing all of those client secrets > would still remain a *huge* (operational) security and scalability issue. > > There is therefore a desire among communities that have such deployments > to be able to re-use the key-management already in place for OAUTH2. > > Note that this example isn't tied to the SAML protocol at all. > > Leif > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://www.ietf.org/mail-archive/web/oauth/attachments/20121108/89d3b3f1/attachment.htm> > > ------------------------------ > > Message: 2 > Date: Thu, 8 Nov 2012 12:43:21 -0500 > From: John Bradley <[email protected]> > To: "Richer, Justin P." <[email protected]> > Cc: "[email protected]" > <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [OAUTH-WG] [Openid-specs-ab] I-D Action: > draft-ietf-oauth-dyn-reg-01.txt > Message-ID: <[email protected]> > Content-Type: text/plain; charset="windows-1252" > > 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." <[email protected]> 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. <[email protected]> > >> 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: [email protected] [[email protected]] on behalf of > >> [email protected] [[email protected]] > >> Sent: Monday, November 05, 2012 5:12 PM > >> To: [email protected] > >> Cc: [email protected] > >> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > >> _______________________________________________ > >> OAuth mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > _______________________________________________ > > Openid-specs-ab mailing list > > [email protected] > > http://lists.openid.net/mailman/listinfo/openid-specs-ab > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://www.ietf.org/mail-archive/web/oauth/attachments/20121108/10d1d87b/attachment.htm> > > ------------------------------ > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > End of OAuth Digest, Vol 49, Issue 9 > ************************************
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
