Thanks, John! Sent from my iPhone
> On Feb 24, 2015, at 9:03 PM, John Bradley <ve7...@ve7jtb.com> wrote: > > Yes as one of the Authors and a officer of the OpenID Foundation the text was > contributed in accordance with the OIDF copyright, allowing derivative works. > > The OIDF is well aware of this specification and is pleased to contribute > parts of the connect specification that have broader applicability in the > OAuth community for inclusion in IETF specifications. > > John B. > >> On Feb 24, 2015, at 8:02 PM, Kathleen Moriarty >> <kathleen.moriarty.i...@gmail.com> wrote: >> >> I was able to get a response, I'm guessing the question got too buried in >> the thread over the past few days. >> >> Essentially, it is the contributors responsibility to ensure it's ok to >> include text. If this was Mike or someone else that believe it is fine, >> then we can proceed. >> >> Hannes may need to update the shepherd report and I'll read through the >> updated version tomorrow. I'll try to get a review out if the accompanying >> management draft tomorrow too. >> >> Thanks, >> Kathleen >> >> Sent from my iPhone >> >>> On 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 >>> athttp://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. >>> >>> -- 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 >> _______________________________________________ >> 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
