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:oauth-bounces@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.tschofenig@gmx.net <mailto:hannes.tschofenig@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.ietf@gmail.com
> <mailto:kathleen.moriarty.ietf@gmail.com>
>  >> <mailto:kathleen.moriarty.ietf@gmail.com
> <mailto:kathleen.moriarty.ietf@gmail.com>>> wrote:
>  >>
>  >>
>  >>
>  >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <ve7jtb@ve7jtb.com
> <mailto:ve7jtb@ve7jtb.com>
>  >> <mailto:ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>>> wrote:
>  >>
>  >>     snip
>  >>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>  >>>     <kathleen.moriarty.ietf@gmail.com
> <mailto:kathleen.moriarty.ietf@gmail.com>
>  >>>     <mailto:kathleen.moriarty.ietf@gmail.com
> <mailto:kathleen.moriarty.ietf@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> <mailto:OAuth@ietf.org
> <mailto:OAuth@ietf.org>>
>  >> https://www.ietf.org/mailman/listinfo/oauth
>
>  >
>  >
>  >
>  > _______________________________________________
>  > OAuth mailing list
>  > OAuth@ietf.org <mailto: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
>

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