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

Reply via email to