Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

[Kathleen Moriarty <[e-mail]>]

Hi Mike,

On Tue, Feb 24, 2015 at 6:47 PM, Mike Jones <[e-mail]>
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:[e-mail]] *On Behalf Of *Kathleen
> Moriarty
> *Sent:* Tuesday, February 24, 2015 3:08 PM
> *To:* Hannes Tschofenig
> *Cc:* [e-mail]
> *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 <
> [e-mail]> 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
> >> <[e-mail]
> >> <mailto:[e-mail]>> wrote:
> >>
> >>
> >>
> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <[e-mail]
> >> <mailto:[e-mail]>> wrote:
> >>
> >>     snip
> >>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
> >>>     <[e-mail]
> >>>     <mailto:[e-mail]>> 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
> >> [e-mail] <mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/oauth
>
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>



-- 

Best regards,
Kathleen