Hi Mike, On Tue, Feb 24, 2015 at 6:47 PM, Mike Jones <michael.jo...@microsoft.com> wrote:
> Thanks, Kathleen. This had been discussed on the OAuth list before, but > just in case you or the IETF legal counsel weren’t aware of it – the reason > that it’s OK to produce derivative works from OpenID specs, as > draft-ietf-oauth-dyn-reg did, is that it’s explicitly allowed by the OpenID > Foundation. See this text at > http://openid.net/specs/openid-connect-registration-1_0.html#Notices – > the spec from which text was copied: > > > > The OpenID Foundation (OIDF) grants to any Contributor, developer, > implementer, or other interested party a non-exclusive, royalty free, > worldwide copyright license to reproduce, prepare derivative works from, > distribute, perform and display, this Implementers Draft or Final > Specification solely for the purposes of (i) developing specifications, and > (ii) implementing Implementers Drafts and Final Specifications based on > such documents, provided that attribution be made to the OIDF as the source > of the material, but that such attribution does not indicate an endorsement > by the OIDF. > > > > You could pass that on to the appropriate IETF legal counsel if they’re > not already aware of it. > Thank you. This was in Hannes message that I sent to the trust to review already. I'll chat with the chairs when they resurface from day jobs/travel and we will figure this out. Thanks, Kathleen > > > -- Mike > > > > *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Kathleen > Moriarty > *Sent:* Tuesday, February 24, 2015 3:08 PM > *To:* Hannes Tschofenig > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg > > > > Hello, > > > > Thanks for updating the draft. I just want to confirm that Hannes is okay > with the updated definitions and updates the shepherd report to reflect > that. > > > > This is getting held up a bit while we sort through copyright of text from > UMA and OpenID. The text from UMA went into an IETF draft, so that should > be the reference as it clears up any possible issues as they provided that > text in an IETF draft. > > > > The chairs will be helping to sort out the requirements with OpenID, per > our discussions the IETF trustees. I'm not sure how long this will take, > but wanted to provide a status so no one thought this had been dropped. > > > > Thanks. > > > > On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig < > hannes.tschofe...@gmx.net> wrote: > > Hi Justin, Hi John, > > I believe that provisioning a client with a unique id (which is what a > client id/client secret is) allows some form of linkability. While it > may be possible to associate the client to a specific user I could very > well imagine that the correlation between activities from a user and > those from the client (particularly when the client is running on the > user's device) is quite possible. > > Ciao > Hannes > > On 02/18/2015 06:37 PM, Justin Richer wrote: > > I’ll incorporate this feedback into another draft, to be posted by the > > end of the week. Thanks everyone! > > > > — Justin > > > >> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty > >> <kathleen.moriarty.i...@gmail.com > >> <mailto:kathleen.moriarty.i...@gmail.com>> wrote: > >> > >> > >> > >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <ve7...@ve7jtb.com > >> <mailto:ve7...@ve7jtb.com>> wrote: > >> > >> snip > >>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty > >>> <kathleen.moriarty.i...@gmail.com > >>> <mailto:kathleen.moriarty.i...@gmail.com>> wrote: > >>> > >>> > The client_id *could* be short lived, but they usually > aren't. I don't see any particular logging or tracking concerns using a > dynamic OAuth client above using any other piece of software, ever. As > such, I don't think it requires special calling out here. > >>> > >>> > >>> Help me understand why there should not be text that shows this > >>> is not an issue or please propose some text. This is bound to > >>> come up in IESG reviews if not addressed up front. > >>> > >>> > >> > >> The client_id is used to communicate to the Authorization server > >> to get a code or refresh token. Those tokens uniquely identify > >> the user from a privacy perspective. > >> It is the access tokens that are sent to the RS and those can and > >> should be rotated, but the client)id is not sent to the RS in > >> OAuth as part of the spec. > >> > >> If you did rotate the client_id then the AS would track it across > >> rotations, so it wouldn’t really achieve anything. > >> > >> One thing we don’t do is allow the client to specify the > >> client_id, that could allow correlation of the client across > >> multiple AS and that might be a privacy issue, but we don’t allow > it. > >> > >> > >> Thanks, John. It may be helpful to add in this explanation unless > >> there is some reason not to? > >> > >> > >> John B. > >> > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org <mailto:OAuth@ietf.org> > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > -- > > > > Best regards, > > Kathleen > -- Best regards, Kathleen
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
