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

[Kathleen Moriarty]

Thank you, I just reviewed the diff and the changes to the draft look good.

Best regards,
Kathleen

On Wed, Feb 25, 2015 at 11:23 AM, Justin Richer  wrote:

> John’s assessment is correct and this is what we’ve tried to capture in
> the privacy considerations section of the latest draft:
>
>In general, the metadata for a client, such as the client name and
>software identifier, are common across all instances of a piece of
>client software and therefore pose no privacy issues for end-users.
>Client identifiers, on the other hand, are often unique to a specific
>instance of a client.  For clients such as web sites that are used by
>many users, there may not be significant privacy concerns regarding
>the client identifier, but for clients such as native applications
>that are installed on a single end-user's device, the client
>identifier could be uniquely tracked during OAuth 2.0 transactions
>and its use tied to that single end-user.  However, as the client
>software still needs to be authorized by a resource owner through an
>OAuth 2.0 authorization grant, this type of tracking can occur
>whether or not the client identifier is unique by correlating the
>authenticated resource owner with the requesting client identifier.
>
>Note that clients are forbidden by this specification from creating
>their own client identifier.  If the client were able to do so, an
>individual client instance could be tracked across multiple colluding
>authorization servers, leading to privacy and security issues.
>Additionally, client identifiers are generally issued uniquely per
>registration request, even for the same instance of software.  In
>this way, an application could marginally improve privacy by
>registering multiple times and appearing to be completely separate
>applications.  However, this technique does incur significant
>usability cost in the form of requiring multiple authorizations per
>resource owner and is therefore unlikely to be used in practice.
>
>
> Hopefully this is more clear now.
>
> Thanks for the feedback and close review,
>  — Justin
>
> > On Feb 24, 2015, at 8:55 PM, John Bradley  wrote:
> >
> > 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 <
> 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
> >>

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

[Justin Richer]

John’s assessment is correct and this is what we’ve tried to capture in the 
privacy considerations section of the latest draft:

   In general, the metadata for a client, such as the client name and
   software identifier, are common across all instances of a piece of
   client software and therefore pose no privacy issues for end-users.
   Client identifiers, on the other hand, are often unique to a specific
   instance of a client.  For clients such as web sites that are used by
   many users, there may not be significant privacy concerns regarding
   the client identifier, but for clients such as native applications
   that are installed on a single end-user's device, the client
   identifier could be uniquely tracked during OAuth 2.0 transactions
   and its use tied to that single end-user.  However, as the client
   software still needs to be authorized by a resource owner through an
   OAuth 2.0 authorization grant, this type of tracking can occur
   whether or not the client identifier is unique by correlating the
   authenticated resource owner with the requesting client identifier.

   Note that clients are forbidden by this specification from creating
   their own client identifier.  If the client were able to do so, an
   individual client instance could be tracked across multiple colluding
   authorization servers, leading to privacy and security issues.
   Additionally, client identifiers are generally issued uniquely per
   registration request, even for the same instance of software.  In
   this way, an application could marginally improve privacy by
   registering multiple times and appearing to be completely separate
   applications.  However, this technique does incur significant
   usability cost in the form of requiring multiple authorizations per
   resource owner and is therefore unlikely to be used in practice.


Hopefully this is more clear now.

Thanks for the feedback and close review,
 — Justin

> On Feb 24, 2015, at 8:55 PM, John Bradley  wrote:
> 
> 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

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 

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  <mailto: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 
>> <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 <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 <mailto: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>
>> >> <mailto:kathleen.moriarty.i...@gmail.com 
>> >> <mailto:kathleen.moriarty.i...@gmail.com>>> wrote:
>> >&

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

[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
> >>  >> <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 refres

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

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

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
> >>  >> <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)i

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

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

[Kathleen Moriarty]

On Wed, Feb 18, 2015 at 4:45 PM, Sam Hartman  wrote:

> > "Kathleen" == Kathleen Moriarty 
> writes:
>
> Kathleen> registry, but setting HTTP Basic as the default seems like
> Kathleen> a really bad choice. HOBA is on it's way to becoming an
> Kathleen> RFC from the HTTPAuth working group.  HTTPAuth also has an
> Kathleen> updated version of Basic that is in IETF last call, but I
> Kathleen> know you are pointing to the OAuth 2.0 document, so it
> Kathleen> would be that document that gets updated and not this
> Kathleen> draft.  The new version of HTTP Basic fixes some
> Kathleen> internationalization problems and spells out the security
> Kathleen> issues much more clearly, so it probably doesn't matter
> Kathleen> too much to update the reference, but maybe makes it more
> Kathleen> clear that basic is not a secure form of authentication.
> Kathleen> Can you provide some justification as to why this is okay
> Kathleen> to set basic as the default and add that to the draft?
> Kathleen> Section 2.3.1 of OAuth 2.0 just says this MUST be
> Kathleen> implemented, but that any HTTP schemes can be used.  Why
> Kathleen> not register another method and use that instead as the
> Kathleen> default?  You could use digest and there is library
> Kathleen> support.  It's not a great answer, but slightly better
> Kathleen> than passwords with basic.  You could register HOBA and
> Kathleen> use that instead, the only downside is limited library
> Kathleen> support at the moment.
>
>
> I'm disappointed to be reading the above, particularly the last
> sentence, today.
> I'd hope that we'd have a better wide-spread understanding of the issues
> in deploying credentials by this point.
>
> Yes, you absolutely can choose whatever you like as the authentication
> scheme for a single-use account.  If my account will only be used with a
> particularly dynamically registration then I probably can get away with
> choosing whatever I want as a default authentication and statements like
> "the only down-side will be limited library availability," will be true.
>
> However, a lot of deployments re-use accounts.  That is, the
> deploymentwill allow some form of single sign-on.  The same account may
> be used for an oauth dynamic registration as well as a bunch of other
> things.
> Even more of an issue, the backend database of credentials may already
> exist and may not be defined by this particular application.
>
> Digest is absolutely impossible to use if I've got a database of  NTLM
> hashes (read Active Directory) that are my credentials.  (In the
> particular case of AD and digest, you probably have a solution if you
> are using Microsoft's implementation.)
> However, if I've got some relational (or nosql) database storing hashes
> that  I've been accumulating as I sign up users for the last few years,
> I can only use authentication schemes compatible with those hashes.
>
>
> The huge deployment advantage of basic is that if you present me the
> password, I can match against whatever I have on the backend.  I can try
> various normalizations, try code-page conversions, rehash, whatever.
> If your client implements scram, and I have NTLM, we're never going to
> be able to talk.  Me implementing scram doesn't help if that's not how
> I've got credentials stored.
>
> Put another way, end protocols like this are not the right place to
> fight passwords.  You transition credential technologies at the
> deployment level, not at the protocol level.
>
> For interoperability in something like this we're likely going to do no
> better than basic.  Anything else from httpauth will fall squarely into
> the category of MUST BUT WE KNOW YOU WON't for some significant
> deployments.
>
> What I've said above doesn't apply particularly to protocols where the
> credentials will not be reused.
>
> I'd be happy to talk some time about strategies for giving deployments
> the tools they need to move their credential interface away from
> passwords, but it does need to be thought of as a deployment issue
> crossing all the applications and protocols that a set of credentials
> use.  This is the wrong place to fight that battle.
>

Sam,

You may have missed part of the thread.  I did not ask the WG to fix it
here, just noted that I don't like that passwords is the best that we can
do and there is no other more secure option registered.  The WG will take a
look at this and see if other options are feasible.  An approach Justin is
working on was provided, but I haven't had time to read that yet.  If
something gets done, it was already agreed that it would be in a separate
draft, I did not ask for it to be done here.

Thanks,
Kathleen

>
> --Sam
>



-- 

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

[Sam Hartman]

> "Kathleen" == Kathleen Moriarty  writes:

Kathleen> registry, but setting HTTP Basic as the default seems like
Kathleen> a really bad choice. HOBA is on it's way to becoming an
Kathleen> RFC from the HTTPAuth working group.  HTTPAuth also has an
Kathleen> updated version of Basic that is in IETF last call, but I
Kathleen> know you are pointing to the OAuth 2.0 document, so it
Kathleen> would be that document that gets updated and not this
Kathleen> draft.  The new version of HTTP Basic fixes some
Kathleen> internationalization problems and spells out the security
Kathleen> issues much more clearly, so it probably doesn't matter
Kathleen> too much to update the reference, but maybe makes it more
Kathleen> clear that basic is not a secure form of authentication.
Kathleen> Can you provide some justification as to why this is okay
Kathleen> to set basic as the default and add that to the draft?
Kathleen> Section 2.3.1 of OAuth 2.0 just says this MUST be
Kathleen> implemented, but that any HTTP schemes can be used.  Why
Kathleen> not register another method and use that instead as the
Kathleen> default?  You could use digest and there is library
Kathleen> support.  It's not a great answer, but slightly better
Kathleen> than passwords with basic.  You could register HOBA and
Kathleen> use that instead, the only downside is limited library
Kathleen> support at the moment.  


I'm disappointed to be reading the above, particularly the last
sentence, today.
I'd hope that we'd have a better wide-spread understanding of the issues
in deploying credentials by this point.

Yes, you absolutely can choose whatever you like as the authentication
scheme for a single-use account.  If my account will only be used with a
particularly dynamically registration then I probably can get away with
choosing whatever I want as a default authentication and statements like
"the only down-side will be limited library availability," will be true.

However, a lot of deployments re-use accounts.  That is, the
deploymentwill allow some form of single sign-on.  The same account may
be used for an oauth dynamic registration as well as a bunch of other
things.
Even more of an issue, the backend database of credentials may already
exist and may not be defined by this particular application.

Digest is absolutely impossible to use if I've got a database of  NTLM
hashes (read Active Directory) that are my credentials.  (In the
particular case of AD and digest, you probably have a solution if you
are using Microsoft's implementation.)
However, if I've got some relational (or nosql) database storing hashes
that  I've been accumulating as I sign up users for the last few years,
I can only use authentication schemes compatible with those hashes.


The huge deployment advantage of basic is that if you present me the
password, I can match against whatever I have on the backend.  I can try
various normalizations, try code-page conversions, rehash, whatever.
If your client implements scram, and I have NTLM, we're never going to
be able to talk.  Me implementing scram doesn't help if that's not how
I've got credentials stored.

Put another way, end protocols like this are not the right place to
fight passwords.  You transition credential technologies at the
deployment level, not at the protocol level.

For interoperability in something like this we're likely going to do no
better than basic.  Anything else from httpauth will fall squarely into
the category of MUST BUT WE KNOW YOU WON't for some significant
deployments.

What I've said above doesn't apply particularly to protocols where the
credentials will not be reused.

I'd be happy to talk some time about strategies for giving deployments
the tools they need to move their credential interface away from
passwords, but it does need to be thought of as a deployment issue
crossing all the applications and protocols that a set of credentials
use.  This is the wrong place to fight that battle.

--Sam

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Hannes Tschofenig]

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
> 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Hannes Tschofenig]

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
> 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

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 
>> 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

___
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]

On Wed, Feb 18, 2015 at 10:07 AM, John Bradley  wrote:

> snip
>
> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty <
> 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

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

[John Bradley]

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.

John B.



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]

Hi,


On Mon, Feb 16, 2015 at 6:42 PM, Mike Jones 
wrote:

> A few responses and comments are inline below...
>
> > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
> > Sent: Thursday, February 12, 2015 11:47 AM
> > To: Justin Richer
> > Cc: oauth@ietf.org
> > Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
> >
> >
> > Phil
> >
> > @independentid
> > www.independentid.com
> > phil.h...@oracle.com
> >
> > On Feb 11, 2015, at 8:31 PM, Justin Richer  wrote:
> >
> > Kathleen, thanks for the review. Responses inline, though I'm going to
> let the other authors talk about their sections (deployment org, software
> version, etc) directly.
>

Thanks for the quick responses and sorry about my delay, it's a busy week!


> >
> > On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
> > Thank you for your work on this draft and sorry for the delay in my
> review.  Before we progress to IETF last call, I'd like to see what we can
> resolve from the list below.   I am looking at the IPR issues to see if we
> can resolve the outstanding questions as well.
> >
> > The Shepherd report says the following:
> >The document shepherd has raised concerns regarding the fuzzy
> description
> >of the actors (deployment organization, software API publisher, client
> >developer) and their impact on the protocol execution. The working
> >group did not seem to worry about these aspects though.
> >
> > I can see the point after reading the draft.  The interactions are
> written much more clearly in the security considerations section than where
> the flows are described.  Can something be done to address these concerns?
> >
> > Section 1.2
> > Deployment Organization definition:
> > I highly recommend replacing the phrase "simple cloud deployment" with a
> description that accurately reflects what is intended.  If that's within a
> single service provider's network, a single data center, or a single hosted
> data center, I think it would be more clear.
> >
> > Section 1.2 nit:
> > Add the word "be" into the following term definition after "may":
> >   Software API Publisher
> >   The organization that defines a particular web accessible API that
> >   may deployed in one or more deployment environments.
> >
> > [deferred to original author of this text Phil et. al for better wording]
> >
> > [Phil] Agreed with Kathleen's suggestion.
>
Thanks!

>
> I also agree that the wording of the definitions could be clarified.
> Justin, do you want to take a first pass at this or would you like to take
> lead on this, Phil?
>
> > Section 2:
> >
> > Why isn't a more secure option offered and set as the default for
> authentication types? I know I've asked this before and the answer was just
> that you can add something to the registry, but setting HTTP Basic as the
> default seems like a really bad choice. HOBA is on it's way to becoming an
> RFC from the HTTPAuth working group.  HTTPAuth also has an updated version
> of Basic that is in IETF last call, but I know you are pointing to the
> OAuth 2.0 document, so it would be that document that gets updated and not
> this draft.  The new version of HTTP Basic fixes some internationalization
> problems and spells out the security issues much more clearly, so it
> probably doesn't matter too much to update the reference, but maybe makes
> it more clear that basic is not a secure form of authentication.
> >
> > Can you provide some justification as to why this is okay to set basic
> as the default and add that to the draft?  Section 2.3.1 of OAuth 2.0 just
> says this MUST be implemented, but that any HTTP schemes can be used.  Why
> not register another method and use that instead as the default?  You could
> use digest and there is library support.  It's not a great answer, but
> slightly better than passwords with basic.  You could register HOBA and use
> that instead, the only downside is limited library support at the moment.
> >
> > It was our intent to document the methods already defined for use with
> OAuth and provide a registration mechanism for distinguishing between them,
> not to create new client authentication mechanisms. Digest and HOBA simply
> aren't defined for use with OAuth clients yet. It would be simple to do:
> put the client id in the "username" field and the client secret in the
> "password" field of both algorithms. However, I don't believe it's a good
> idea to conflate those two goals in a single sp

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

[Kathleen Moriarty]

Hi,

On Tue, Feb 17, 2015 at 7:03 PM, Phil Hunt  wrote:

> I’m not sure if this is what Kathleen is after. I think part of the
> background in the current spec is that we were trying to differentiate from
> the large scale success stories OAuth has had in the past like Facebook and
> Google.  When you are a developer trying to build a client for IMAP, a
> standards based protocol, you can’t predict what the endpoints are in
> advance, so obviously an IMAP developer can’t obtain client_ids since they
> can’t predict the future. Nor would it be reasonable to pre-register with
> every possible email deployment in the world.
>

For this, I was just after improved text to clarify the definitions after
seeing the issue in the shepherd writeup and seeing it as I read the
draft.  This looks better to me and I'd like the shepherd to weigh in to
make sure he also thinks the updated definitions clarify the intent for him
as well.

Hannes, what do you think?

>
> NOTE:   We might want to change the terminology from “API” to application
> service or application protocol.  I know some an IETF see the word API and
> associate that exclusively with programming libraries.
>
> deployment organization
>   An administrative security domain under which a software API
> (service) is
>   deployed and protected by an OAuth 2.0 framework. In early OAuth
>   scenarios, the deploying organization was often the same organization
>   that published the API. In these cases the deploying organization
> can have
>  a close relationship with client software developers.  In many other
> cases,
>  the definer of the service may be an independent third-party
> publisher or
>  a standards organization. The client software developer while working
> to
>  a published specification for an API is unable to have a prior
> relationship
>  with the organization deploying the software API (service).
>
> software api publisher
>   The organization that defines a particular web accessible API that
>   may be deployed in one or more deployment environments.  A publisher
>   may be any standards body, commercial, public, private, or open
> source
>   organization that is responsible for publishing and distributing
>   software that may be protected via OAuth 2.0.  In some cases a
>   software API publisher and a client developer may be the same
>   organization. At the time of publication of a web accessible API,
> the software
>  publisher often does not have a prior relationship with deploying
> organizations.
>
>  Client Developer
>   The person or organization that builds a client software package
>   and prepares it for distribution. At the time of building the
> client, the developer
>   is often not aware of who the deploying service provider
> organizations will be.
>   Except when the software API publisher and the deploying
> organization are
>   the same, client developers will need to use dynamic registration
> when they are
>   unable to predict the deployment URLs at “compile time”.
>

Thank you,
Kathleen

>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
> > On Feb 16, 2015, at 4:43 PM, Justin Richer  wrote:
> >
> > To Mike's last question below: I'd like Phil (and others if desired) to
> propose a clarified version of the "deployment organization", "software api
> publisher", and "client developer" if possible. With some text for that in
> hand I can tackle the rest given the feedback below.
> >
> > -- Justin
> >
> > On 2/16/2015 6:42 PM, Mike Jones wrote:
> >> A few responses and comments are inline below...
> >>
> >>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
> >>> Sent: Thursday, February 12, 2015 11:47 AM
> >>> To: Justin Richer
> >>> Cc: oauth@ietf.org
> >>> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
> >>>
> >>>
> >>> Phil
> >>>
> >>> @independentid
> >>> www.independentid.com
> >>> phil.h...@oracle.com
> >>>
> >>> On Feb 11, 2015, at 8:31 PM, Justin Richer  wrote:
> >>>
> >>> Kathleen, thanks for the review. Responses inline, though I'm going to
> let the other authors talk about their sections (deployment org, software
> version, etc) directly.
> >>>
> >>> On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
> >>> Thank you for your work on this draft and sorry for the delay in my
> review.  Before we progress to IETF last call, I'd like to s

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

[Phil Hunt]

I’m not sure if this is what Kathleen is after. I think part of the background 
in the current spec is that we were trying to differentiate from the large 
scale success stories OAuth has had in the past like Facebook and Google.  When 
you are a developer trying to build a client for IMAP, a standards based 
protocol, you can’t predict what the endpoints are in advance, so obviously an 
IMAP developer can’t obtain client_ids since they can’t predict the future. Nor 
would it be reasonable to pre-register with every possible email deployment in 
the world.

NOTE:   We might want to change the terminology from “API” to application 
service or application protocol.  I know some an IETF see the word API and 
associate that exclusively with programming libraries.

deployment organization
  An administrative security domain under which a software API (service) is
  deployed and protected by an OAuth 2.0 framework. In early OAuth
  scenarios, the deploying organization was often the same organization 
  that published the API. In these cases the deploying organization can 
have 
 a close relationship with client software developers.  In many other cases,
 the definer of the service may be an independent third-party publisher or
 a standards organization. The client software developer while working to
 a published specification for an API is unable to have a prior 
relationship 
 with the organization deploying the software API (service).

software api publisher
  The organization that defines a particular web accessible API that
  may be deployed in one or more deployment environments.  A publisher
  may be any standards body, commercial, public, private, or open source
  organization that is responsible for publishing and distributing
  software that may be protected via OAuth 2.0.  In some cases a
  software API publisher and a client developer may be the same
  organization. At the time of publication of a web accessible API, the 
software
 publisher often does not have a prior relationship with deploying 
organizations.

 Client Developer
  The person or organization that builds a client software package
  and prepares it for distribution. At the time of building the client, the 
developer
  is often not aware of who the deploying service provider organizations 
will be. 
  Except when the software API publisher and the deploying organization are 
  the same, client developers will need to use dynamic registration when 
they are
  unable to predict the deployment URLs at “compile time”.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com

> On Feb 16, 2015, at 4:43 PM, Justin Richer  wrote:
> 
> To Mike's last question below: I'd like Phil (and others if desired) to 
> propose a clarified version of the "deployment organization", "software api 
> publisher", and "client developer" if possible. With some text for that in 
> hand I can tackle the rest given the feedback below.
> 
> -- Justin
> 
> On 2/16/2015 6:42 PM, Mike Jones wrote:
>> A few responses and comments are inline below...
>> 
>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
>>> Sent: Thursday, February 12, 2015 11:47 AM
>>> To: Justin Richer
>>> Cc: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
>>> 
>>> 
>>> Phil
>>> 
>>> @independentid
>>> www.independentid.com
>>> phil.h...@oracle.com
>>> 
>>> On Feb 11, 2015, at 8:31 PM, Justin Richer  wrote:
>>> 
>>> Kathleen, thanks for the review. Responses inline, though I'm going to let 
>>> the other authors talk about their sections (deployment org, software 
>>> version, etc) directly.
>>> 
>>> On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
>>> Thank you for your work on this draft and sorry for the delay in my review. 
>>>  Before we progress to IETF last call, I'd like to see what we can resolve 
>>> from the list below.   I am looking at the IPR issues to see if we can 
>>> resolve the outstanding questions as well.
>>> 
>>> The Shepherd report says the following:
>>>The document shepherd has raised concerns regarding the fuzzy description
>>>of the actors (deployment organization, software API publisher, client
>>>developer) and their impact on the protocol execution. The working
>>>group did not seem to worry about these aspects though.
>>> 
>>> I can see the point after reading the draft.  The interactions are written 
>>> much more clearly in the security considerations section than where the 
>>> flows are described.

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

[Justin Richer]

To Mike's last question below: I'd like Phil (and others if desired) to 
propose a clarified version of the "deployment organization", "software 
api publisher", and "client developer" if possible. With some text for 
that in hand I can tackle the rest given the feedback below.


 -- Justin

On 2/16/2015 6:42 PM, Mike Jones wrote:

A few responses and comments are inline below...


From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, February 12, 2015 11:47 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg


Phil

@independentid
www.independentid.com
phil.h...@oracle.com

On Feb 11, 2015, at 8:31 PM, Justin Richer  wrote:

Kathleen, thanks for the review. Responses inline, though I'm going to let the 
other authors talk about their sections (deployment org, software version, etc) 
directly.

On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
Thank you for your work on this draft and sorry for the delay in my review.  
Before we progress to IETF last call, I'd like to see what we can resolve from 
the list below.   I am looking at the IPR issues to see if we can resolve the 
outstanding questions as well.

The Shepherd report says the following:
The document shepherd has raised concerns regarding the fuzzy description
of the actors (deployment organization, software API publisher, client
developer) and their impact on the protocol execution. The working
group did not seem to worry about these aspects though.

I can see the point after reading the draft.  The interactions are written much 
more clearly in the security considerations section than where the flows are 
described.  Can something be done to address these concerns?

Section 1.2
Deployment Organization definition:
I highly recommend replacing the phrase "simple cloud deployment" with a 
description that accurately reflects what is intended.  If that's within a single service 
provider's network, a single data center, or a single hosted data center, I think it 
would be more clear.

Section 1.2 nit:
Add the word "be" into the following term definition after "may":
   Software API Publisher
   The organization that defines a particular web accessible API that
   may deployed in one or more deployment environments.

[deferred to original author of this text Phil et. al for better wording]

[Phil] Agreed with Kathleen's suggestion.

I also agree that the wording of the definitions could be clarified.  Justin, 
do you want to take a first pass at this or would you like to take lead on 
this, Phil?


Section 2:

Why isn't a more secure option offered and set as the default for 
authentication types? I know I've asked this before and the answer was just 
that you can add something to the registry, but setting HTTP Basic as the 
default seems like a really bad choice. HOBA is on it's way to becoming an RFC 
from the HTTPAuth working group.  HTTPAuth also has an updated version of Basic 
that is in IETF last call, but I know you are pointing to the OAuth 2.0 
document, so it would be that document that gets updated and not this draft.  
The new version of HTTP Basic fixes some internationalization problems and 
spells out the security issues much more clearly, so it probably doesn't matter 
too much to update the reference, but maybe makes it more clear that basic is 
not a secure form of authentication.

Can you provide some justification as to why this is okay to set basic as the 
default and add that to the draft?  Section 2.3.1 of OAuth 2.0 just says this 
MUST be implemented, but that any HTTP schemes can be used.  Why not register 
another method and use that instead as the default?  You could use digest and 
there is library support.  It's not a great answer, but slightly better than 
passwords with basic.  You could register HOBA and use that instead, the only 
downside is limited library support at the moment.

It was our intent to document the methods already defined for use with OAuth and provide a 
registration mechanism for distinguishing between them, not to create new client authentication 
mechanisms. Digest and HOBA simply aren't defined for use with OAuth clients yet. It would be 
simple to do: put the client id in the "username" field and the client secret in the 
"password" field of both algorithms. However, I don't believe it's a good idea to 
conflate those two goals in a single specification. We actually had other, more secure definitions 
in an earlier draft of this document (using a JWT signed with a private key or a JWT signed with a 
shared key, specifically), but those were removed in order to focus on solving just the client 
registration problem. I agree with that decision of the WG.

As other methods of client authentication are defined in the OAuth ecosystem, 
they can register 

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

[Mike Jones]

A few responses and comments are inline below...

> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
> Sent: Thursday, February 12, 2015 11:47 AM
> To: Justin Richer
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
>
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
> On Feb 11, 2015, at 8:31 PM, Justin Richer  wrote:
>
> Kathleen, thanks for the review. Responses inline, though I'm going to let 
> the other authors talk about their sections (deployment org, software 
> version, etc) directly.
>
> On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
> Thank you for your work on this draft and sorry for the delay in my review.  
> Before we progress to IETF last call, I'd like to see what we can resolve 
> from the list below.   I am looking at the IPR issues to see if we can 
> resolve the outstanding questions as well.
>
> The Shepherd report says the following:
>The document shepherd has raised concerns regarding the fuzzy description
>of the actors (deployment organization, software API publisher, client
>developer) and their impact on the protocol execution. The working
>group did not seem to worry about these aspects though.
>
> I can see the point after reading the draft.  The interactions are written 
> much more clearly in the security considerations section than where the flows 
> are described.  Can something be done to address these concerns?
>
> Section 1.2
> Deployment Organization definition:
> I highly recommend replacing the phrase "simple cloud deployment" with a 
> description that accurately reflects what is intended.  If that's within a 
> single service provider's network, a single data center, or a single hosted 
> data center, I think it would be more clear.
>
> Section 1.2 nit:
> Add the word "be" into the following term definition after "may":
>   Software API Publisher
>   The organization that defines a particular web accessible API that
>   may deployed in one or more deployment environments.
>
> [deferred to original author of this text Phil et. al for better wording]
>
> [Phil] Agreed with Kathleen's suggestion.

I also agree that the wording of the definitions could be clarified.  Justin, 
do you want to take a first pass at this or would you like to take lead on 
this, Phil?

> Section 2:
>
> Why isn't a more secure option offered and set as the default for 
> authentication types? I know I've asked this before and the answer was just 
> that you can add something to the registry, but setting HTTP Basic as the 
> default seems like a really bad choice. HOBA is on it's way to becoming an 
> RFC from the HTTPAuth working group.  HTTPAuth also has an updated version of 
> Basic that is in IETF last call, but I know you are pointing to the OAuth 2.0 
> document, so it would be that document that gets updated and not this draft.  
> The new version of HTTP Basic fixes some internationalization problems and 
> spells out the security issues much more clearly, so it probably doesn't 
> matter too much to update the reference, but maybe makes it more clear that 
> basic is not a secure form of authentication.
>
> Can you provide some justification as to why this is okay to set basic as the 
> default and add that to the draft?  Section 2.3.1 of OAuth 2.0 just says this 
> MUST be implemented, but that any HTTP schemes can be used.  Why not register 
> another method and use that instead as the default?  You could use digest and 
> there is library support.  It's not a great answer, but slightly better than 
> passwords with basic.  You could register HOBA and use that instead, the only 
> downside is limited library support at the moment.
>
> It was our intent to document the methods already defined for use with OAuth 
> and provide a registration mechanism for distinguishing between them, not to 
> create new client authentication mechanisms. Digest and HOBA simply aren't 
> defined for use with OAuth clients yet. It would be simple to do: put the 
> client id in the "username" field and the client secret in the "password" 
> field of both algorithms. However, I don't believe it's a good idea to 
> conflate those two goals in a single specification. We actually had other, 
> more secure definitions in an earlier draft of this document (using a JWT 
> signed with a private key or a JWT signed with a shared key, specifically), 
> but those were removed in order to focus on solving just the client 
> registration problem. I agree with that decision of the WG.
>
> As other methods of client authentication are defined in the 

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

[Phil Hunt]

Phil

@independentid
www.independentid.com
phil.h...@oracle.com

> On Feb 11, 2015, at 8:31 PM, Justin Richer  wrote:
> 
> Kathleen, thanks for the review. Responses inline, though I'm going to let 
> the other authors talk about their sections (deployment org, software 
> version, etc) directly.
> 
> On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
>> Thank you for your work on this draft and sorry for the delay in my review.  
>> Before we progress to IETF last call, I'd like to see what we can resolve 
>> from the list below.   I am looking at the IPR issues to see if we can 
>> resolve the outstanding questions as well.
>> 
>> The Shepherd report says the following:
>>The document shepherd has raised concerns regarding the fuzzy description
>>of the actors (deployment organization, software API publisher, client 
>>developer) and their impact on the protocol execution. The working 
>>group did not seem to worry about these aspects though.
>> 
>> I can see the point after reading the draft.  The interactions are written 
>> much more clearly in the security considerations section than where the 
>> flows are described.  Can something be done to address these concerns?
>> 
>> Section 1.2
>> Deployment Organization definition:
>> I highly recommend replacing the phrase "simple cloud deployment" with a 
>> description that accurately reflects what is intended.  If that's within a 
>> single service provider's network, a single data center, or a single hosted 
>> data center, I think it would be more clear.
>> 
>> Section 1.2 nit:
>> Add the word "be" into the following term definition after "may":
>>   Software API Publisher
>>   The organization that defines a particular web accessible API that
>>   may deployed in one or more deployment environments. 
> 
> [deferred to original author of this text Phil et. al for better wording]

[Phil] Agreed with Kathleen’s suggestion.
> 
>> 
>> Section 2:
>> 
>> Why isn't a more secure option offered and set as the default for 
>> authentication types? I know I've asked this before and the answer was just 
>> that you can add something to the registry, but setting HTTP Basic as the 
>> default seems like a really bad choice. HOBA is on it's way to becoming an 
>> RFC from the HTTPAuth working group.  HTTPAuth also has an updated version 
>> of Basic that is in IETF last call, but I know you are pointing to the OAuth 
>> 2.0 document, so it would be that document that gets updated and not this 
>> draft.  The new version of HTTP Basic fixes some internationalization 
>> problems and spells out the security issues much more clearly, so it 
>> probably doesn't matter too much to update the reference, but maybe makes it 
>> more clear that basic is not a secure form of authentication.  
>> 
>> Can you provide some justification as to why this is okay to set basic as 
>> the default and add that to the draft?  Section 2.3.1 of OAuth 2.0 just says 
>> this MUST be implemented, but that any HTTP schemes can be used.  Why not 
>> register another method and use that instead as the default?  You could use 
>> digest and there is library support.  It's not a great answer, but slightly 
>> better than passwords with basic.  You could register HOBA and use that 
>> instead, the only downside is limited library support at the moment.
> 
> It was our intent to document the methods already defined for use with OAuth 
> and provide a registration mechanism for distinguishing between them, not to 
> create new client authentication mechanisms. Digest and HOBA simply aren't 
> defined for use with OAuth clients yet. It would be simple to do: put the 
> client id in the "username" field and the client secret in the "password" 
> field of both algorithms. However, I don't believe it's a good idea to 
> conflate those two goals in a single specification. We actually had other, 
> more secure definitions in an earlier draft of this document (using a JWT 
> signed with a private key or a JWT signed with a shared key, specifically), 
> but those were removed in order to focus on solving just the client 
> registration problem. I agree with that decision of the WG.
> 
> As other methods of client authentication are defined in the OAuth ecosystem, 
> they can register as valid values in the registry. I think it would be a 
> valuable output of this WG to define other client authentication mechanisms 
> as a separate draft or an eventual update to RFC6749 (or both?). 
> 
>> 
>> Section 2: Contacts:
>> 
>> I noticed privacy is not dealt with until you get to the security 
>> considerations section.  I'd prefer to see it with the definition, stating 
>> the address should be a general help address at the domain rather than 
>> directly to an identifiable individual.  It may be good to set a default for 
>> what this should be for consistency or give an example (think back to 
>> ab...@domain.com )?
> 
> The problem that I see with putting it inside 

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

[Justin Richer]

Kathleen, thanks for the review. Responses inline, though I'm going to 
let the other authors talk about their sections (deployment org, 
software version, etc) directly.


On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
Thank you for your work on this draft and sorry for the delay in my 
review.  Before we progress to IETF last call, I'd like to see what we 
can resolve from the list below.   I am looking at the IPR issues to 
see if we can resolve the outstanding questions as well.


The Shepherd report says the following:
   The document shepherd has raised concerns regarding the fuzzy 
description

   of the actors (deployment organization, software API publisher, client
   developer) and their impact on the protocol execution. The working
   group did not seem to worry about these aspects though.

I can see the point after reading the draft.  The interactions are 
written much more clearly in the security considerations section than 
where the flows are described.  Can something be done to address these 
concerns?


Section 1.2
Deployment Organization definition:
I highly recommend replacing the phrase "simple cloud deployment" with 
a description that accurately reflects what is intended.  If that's 
within a single service provider's network, a single data center, or a 
single hosted data center, I think it would be more clear.


Section 1.2 nit:
Add the word "be" into the following term definition after "may":
  Software API Publisher
  The organization that defines a particular web accessible API that
  may deployed in one or more deployment environments.


[deferred to original author of this text Phil et. al for better wording]



Section 2:

Why isn't a more secure option offered and set as the default for 
authentication types? I know I've asked this before and the answer was 
just that you can add something to the registry, but setting HTTP 
Basic as the default seems like a really bad choice. HOBA is on it's 
way to becoming an RFC from the HTTPAuth working group.  HTTPAuth also 
has an updated version of Basic that is in IETF last call, but I know 
you are pointing to the OAuth 2.0 document, so it would be that 
document that gets updated and not this draft.  The new version of 
HTTP Basic fixes some internationalization problems and spells out the 
security issues much more clearly, so it probably doesn't matter too 
much to update the reference, but maybe makes it more clear that basic 
is not a secure form of authentication.


Can you provide some justification as to why this is okay to set basic 
as the default and add that to the draft?  Section 2.3.1 of OAuth 2.0 
just says this MUST be implemented, but that any HTTP schemes can be 
used.  Why not register another method and use that instead as the 
default?  You could use digest and there is library support.  It's not 
a great answer, but slightly better than passwords with basic.  You 
could register HOBA and use that instead, the only downside is limited 
library support at the moment.


It was our intent to document the methods already defined for use with 
OAuth and provide a registration mechanism for distinguishing between 
them, not to create new client authentication mechanisms. Digest and 
HOBA simply aren't defined for use with OAuth clients yet. It would be 
simple to do: put the client id in the "username" field and the client 
secret in the "password" field of both algorithms. However, I don't 
believe it's a good idea to conflate those two goals in a single 
specification. We actually had other, more secure definitions in an 
earlier draft of this document (using a JWT signed with a private key or 
a JWT signed with a shared key, specifically), but those were removed in 
order to focus on solving just the client registration problem. I agree 
with that decision of the WG.


As other methods of client authentication are defined in the OAuth 
ecosystem, they can register as valid values in the registry. I think it 
would be a valuable output of this WG to define other client 
authentication mechanisms as a separate draft or an eventual update to 
RFC6749 (or both?).




Section 2: Contacts:

I noticed privacy is not dealt with until you get to the security 
considerations section.  I'd prefer to see it with the definition, 
stating the address should be a general help address at the domain 
rather than directly to an identifiable individual.  It may be good to 
set a default for what this should be for consistency or give an 
example (think back to ab...@domain.com )?


The problem that I see with putting it inside the definition is that it 
makes the definition text very long, as the definition sits in a list of 
other metadata items. We could add a forward pointer and an example 
easily enough, though. Or we could move the privacy considerations 
section up as a subsection here, though I don't know if that runs afoul 
of the RFC style guidelines for this new section.




Software_id and s