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

[Mike Jones <[e-mail]>]

Not that I'm aware of.

-----Original Message-----
From: OAuth [mailto:[e-mail]] On Behalf Of Bill Burke
Sent: Tuesday, February 24, 2015 3:59 PM
To: [e-mail]
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

Is there plans to derive from any other parts of openid connect and bring them into IETF/OAuth?

Thanks.

On 2/24/2015 6:47 PM, Mike Jones 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.
>
>                                                                  -- 
> 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] <mailto:[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]>
>  >> <mailto:[e-mail]
> <mailto:[e-mail]>>> wrote:
>  >>
>  >>
>  >>
>  >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <[e-mail] 
> <mailto:[e-mail]>  >> <mailto:[e-mail] 
> <mailto:[e-mail]>>> wrote:
>  >>
>  >>     snip
>  >>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>  >>>     <[e-mail]
> <mailto:[e-mail]>
>  >>>     <mailto:[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]> <mailto:[e-mail] 
> <mailto:[e-mail]>>  >> 
> https://www.ietf.org/mailman/listinfo/oauth
>
>  >
>  >
>  >
>  > _______________________________________________
>  > OAuth mailing list
>  > [e-mail] <mailto:[e-mail]>  > 
> https://www.ietf.org/mailman/listinfo/oauth
>  >
>
>
>
> --
>
> Best regards,
>
> Kathleen
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth