Re: [OAUTH-WG] Improper use of 'Pragma: no-cache' response header in OAuth 2.0 RFCs?

[Brian Campbell]

I know it's kind of a trivial issue but I was hoping that at least a couple
people would either agree with me or explain why I'm wrong.


On Thu, Feb 19, 2015 at 4:47 PM, Brian Campbell 
wrote:

> Examples in RFC 6750  and RFC 6749
>  as well as some normative text in section
> 5.1 of RFC 6749  use a
> "Pragma: no-cache" HTTP response header. However, both RFC 2616
>  and the shiny new RFC
> 7234  make special note
> along the lines of the following to say that it doesn't work as response
> header:
>
>'Note: Because the meaning of "Pragma: no-cache" in responses is
> not specified, it does not provide a reliable replacement for
> "Cache-Control: no-cache" in them.'
>
>
> The header doesn't hurt anything, I don't think, so having it in these
> documents isn't really a problem. But it seems like it'd be better to not
> further perpetuate the "Pragma: no-cache" response header myth in actual
> published RFCs.
>
> So with that said, two questions:
>
> 1) Do folks agree that 6747/6750 are using the "Pragma: no-cache" response
> header inappropriately?
>
> 2) If so, does this qualify as errata?
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Improper use of 'Pragma: no-cache' response header in OAuth 2.0 RFCs?

[John Bradley]

Yes, so we should track it but I don’t think it rises to the level of an errata 
on its own. 
> On Feb 19, 2015, at 6:47 PM, Brian Campbell  
> wrote:
> 
> Examples in RFC 6750  and RFC 6749 
>  as well as some normative text in 
> section 5.1 of RFC 6749  use 
> a "Pragma: no-cache" HTTP response header. However, both RFC 2616 
>  and the shiny new RFC 7234 
>  make special note along the 
> lines of the following to say that it doesn't work as response header:
> 
>'Note: Because the meaning of "Pragma: no-cache" in responses is
> not specified, it does not provide a reliable replacement for
> "Cache-Control: no-cache" in them.'
> 
> The header doesn't hurt anything, I don't think, so having it in these 
> documents isn't really a problem. But it seems like it'd be better to not 
> further perpetuate the "Pragma: no-cache" response header myth in actual 
> published RFCs.
> 
> So with that said, two questions:
> 
> 1) Do folks agree that 6747/6750 are using the "Pragma: no-cache" response 
> header inappropriately? 
> 
> 2) If so, does this qualify as errata?
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Kathleen Moriarty]

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
> >>  >> > wrote:
> >>
> >>
> >>
> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley  >> > wrote:
> >>
> >> snip
> >>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
> >>>  >>> > 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 
> >> 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

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

[Mike Jones]

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-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 
mailto: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
>> mailto:kathleen.moriarty.i...@gmail.com>
>> >>
>>  wrote:
>>
>>
>>
>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley 
>> mailto:ve7...@ve7jtb.com>
>> >> wrote:
>>
>> snip
>>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>>> 
>>> 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 
>> >
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___
> OAut

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

[Kathleen Moriarty]

Hi Mike,

On Tue, Feb 24, 2015 at 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.
>

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: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
> >>  >> > wrote:
> >>
> >>
> >>
> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley  >> > wrote:
> >>
> >> snip
> >>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
> >>>  >>> > 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
> >> 

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

[Bill Burke]

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-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
mailto: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
 >> mailto:kathleen.moriarty.i...@gmail.com>
 >> >> wrote:
 >>
 >>
 >>
 >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley mailto:ve7...@ve7jtb.com>
 >> >> wrote:
 >>
 >> snip
 >>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
 >>> 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 

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

[Mike Jones]

Not that I'm aware of.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Bill Burke
Sent: Tuesday, February 24, 2015 3:59 PM
To: oauth@ietf.org
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: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 
> mailto: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  >> 
>  
>  >>  >> wrote:
>  >>
>  >>
>  >>
>  >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley    >>  >> wrote:
>  >>
>  >> snip
>  >>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>  >>>  
>  >>>  >> 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

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

[Kathleen Moriarty]

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  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-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 
>  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
> >>  >> > wrote:
> >>
> >>
> >>
> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley  >> > wrote:
> >>
> >> snip
> >>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
> >>>  >>> > 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 mi

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

[John Bradley]

Yes but it is authenticating the client to the AS as part of the resource 
owners consent.   

Ther eis a one to one mapping of resource owner to client in that case. 

The client ID is no more identifying than the refresh token that maps to the RO 
by design.

Yes the grant identifies the RO in some way.  The client_id and secret prevent 
that from being used in a different client if the bearer token leaks.

Remember the client_id is going to be different at different AS as each will 
have a separate registration.
If the client_id was fixed across multiple AS then it would be a correlation 
issue, but that is not the case.

Perhaps I am not understanding the concern?

John B.

> On Feb 18, 2015, at 12:57 PM, Hannes Tschofenig  
> 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
>>> >> > wrote:
>>> 
>>> 
>>> 
>>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley >> > wrote:
>>> 
>>>snip
On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>>>> 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 
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> 
>> ___
>> 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



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[John Bradley]

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 
>  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  > 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 
>> mailto: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
>> >> > >> 
>> >> > >> >> wrote:
>> >>
>> >>
>> >>
>> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley > >> 
>> >> >> wrote:
>> >>
>> >> snip
>> >>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>> >>> > >>> 
>> >>> > >>> >> 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 o

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

[Kathleen Moriarty]

Thanks, John!

Sent from my iPhone

> On Feb 24, 2015, at 9:03 PM, John Bradley  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 
>>  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  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 
>>>  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
>>> >> >> >> > wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley >> >> > wrote:
>>> >>
>>> >> snip
>>> >>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>>> >>> >> >>> > 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 i