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

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 11 Feb 2015 18:06:51 -0500

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.

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.

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
[email-masked])?

Software_id and software_version:
Are there any guidelines as to how these should be represented?  There are
several specifications on software_id (and platform).  Does consistency
here matter or is this just meant to be human readable?
Section 2.2 specifies some metadata values that are to be human readable,
should the above be in the list?  I would expect this list to be
comprehensive for clarity, rather than just examples since there aren't too
many defined here.

Section 3.2.1 & Privacy section
For client_name and client_id and associated information, how is user
privacy affected and what can be done to mitigate concerns?  The definition
should state that this is a public value and that it is specific to the
software, not a person.  You have to get to the security consideration
section before that is clear.  References are fine too, but some more
information is needed in the privacy section.  I'm left with a bunch of
questions:
  Can the client_name and client_id be tied to a person?
  Can the person be tracked by this?
  Can other information be gathered about a system (and it's user) during
this process?
  The information is used to dynamically register clients, what is logged?
  What data is aggregated?
  What can you tell about a client (time, location, travel, other personal
details that may be considered sensitive)?  I don't think this was covered
in the OAuth 2.0 RFC.
  How is this addressed at the authorization server and other points?
  The Security considerations talks about client_id as being short lived,
so they expire, but are these event logged or is that prohibited?

5. Security considerations
The first paragraph is a repeat of text.  Can this just be in one place and
use a pointer to the full text?  I like the requirement, but reading it
once is enough.

-- 

Best regards,
Kathleen

---

From: Justin Richer <[email-masked]>
Date: Wed, 11 Feb 2015 23:31:45 -0500

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

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

> 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?).

> 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 [email-masked] <mailto:[email-masked]>)?

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.

> Are there any guidelines as to how these should be represented?  There 
> are several specifications on software_id (and platform).  Does 
> consistency here matter or is this just meant to be human readable?
> Section 2.2 specifies some metadata values that are to be human 
> readable, should the above be in the list?  I would expect this list 
> to be comprehensive for clarity, rather than just examples since there 
> aren't too many defined here.
>

[mostly deferred to Phil et. al, but note that software_id and 
software_version are not intended to be human readable and don't need 
the multi-language support]

> privacy affected and what can be done to mitigate concerns?  The 
> definition should state that this is a public value and that it is 
> specific to the software, not a person.  You have to get to the 
> security consideration section before that is clear.  References are 
> fine too, but some more information is needed in the privacy section.  
> I'm left with a bunch of questions:
The client name is common across all copies of the software (usually), 
so no worries there. The ID represents an individual piece of software, 
not a person, though if that person is the sole user of the instance of 
software then I believe you're right that there are some privacy 
considerations that we should point that out. However, dynamic 
registration can actually help mitigate this as well, since in the 
normal case (with no software statements) there's no way to correlate 
instances of clients with each other.
>   Can other information be gathered about a system (and it's user) 
> during this process?
Nothing gathered about the user during registration, as this happens in 
the back channel outside the user's purview.
>   What can you tell about a client (time, location, travel, other 
> personal details that may be considered sensitive)?  I don't think 
> this was covered in the OAuth 2.0 RFC.
>   The Security considerations talks about client_id as being short 
> lived, so they expire, but are these event logged or is that prohibited?

Many of these questions seem to be completely dependent on the 
implementation of the authorization server, and I'm not really sure how 
(or if) to address them in this draft. Any suggestions would be welcomed 
here.

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.

> The first paragraph is a repeat of text.  Can this just be in one 
> place and use a pointer to the full text?  I like the requirement, but 
> reading it once is enough.

I think it was less onerous of a repeat when both simply said "use TLS", 
so some refactoring after the expansion of the text makes sense to me. 
Would it be better to have it upfront in the endpoint definition, or in 
the security considerations?

Thanks again for your review!

  -- Justin

>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Thu, 12 Feb 2015 11:46:50 -0800

Phil

@independentid
www.independentid.com
[email-masked]

> On Feb 11, 2015, at 8:31 PM, Justin Richer <[email-masked]> 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.
> 
>> 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.
>> 
>> 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
>> 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:

[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 [email-masked] <mailto:[email-masked]>)?
> 
> 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. 
> 
>> 
>> Are there any guidelines as to how these should be represented?  There are several specifications on software_id (and platform).  Does consistency here matter or is this just meant to be human readable?
>> Section 2.2 specifies some metadata values that are to be human readable, should the above be in the list?  I would expect this list to be comprehensive for clarity, rather than just examples since there aren't too many defined here.
>> 
> 
> [mostly deferred to Phil et. al, but note that software_id and software_version are not intended to be human readable and don't need the multi-language support]

[Phil]
I’ve added some more explanatory text. Note…some of this may be better put elsewhere.  

As to whether the values are human readable, I have no opinion. What matters most is unique matching.

   software_id
      A unique identifier (e.g. UUID) assigned by the developer or software publisher
      used by registration endpoints to identify client software to be dynamically registered. 
      Unlike "client_id", which is issued by the authorization server and varies between
      instances of software, the "software_id” SHOULD remain the same for all client software
      instances. The “software_id” SHOULD remain the same across multiple software updates 
      or versions.

software_version
      A version identifier for the software identified by “software_id".  The
      value of this field is a string that is intended to be compared
      using string equality matching. Unlike “software_id”, the value of the
      "software_version" SHOULD change on any update to the client
      software. A service provider MAY use “software_id" and “software_version" to 
      recognize approved software and version combinations approved for dynamic registration.

Let me know if you want more background.

>> For client_name and client_id and associated information, how is user privacy affected and what can be done to mitigate concerns?  The definition should state that this is a public value and that it is specific to the software, not a person.  You have to get to the security consideration section before that is clear.  References are fine too, but some more information is needed in the privacy section.  I'm left with a bunch of questions:
> The client name is common across all copies of the software (usually), so no worries there. The ID represents an individual piece of software, not a person, though if that person is the sole user of the instance of software then I believe you're right that there are some privacy considerations that we should point that out. However, dynamic registration can actually help mitigate this as well, since in the normal case (with no software statements) there's no way to correlate instances of clients with each other.
>>   Can other information be gathered about a system (and it's user) during this process?  
> Nothing gathered about the user during registration, as this happens in the back channel outside the user's purview.
>>   What can you tell about a client (time, location, travel, other personal details that may be considered sensitive)?  I don't think this was covered in the OAuth 2.0 RFC.
>>   The Security considerations talks about client_id as being short lived, so they expire, but are these event logged or is that prohibited? 
> 
> Many of these questions seem to be completely dependent on the implementation of the authorization server, and I'm not really sure how (or if) to address them in this draft. Any suggestions would be welcomed here.
> 
> 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.
> 
>> 
>> The first paragraph is a repeat of text.  Can this just be in one place and use a pointer to the full text?  I like the requirement, but reading it once is enough. 
> 
> I think it was less onerous of a repeat when both simply said "use TLS", so some refactoring after the expansion of the text makes sense to me. Would it be better to have it upfront in the endpoint definition, or in the security considerations? 
> 
>> 
>> -- 
>> 
>> Best regards,
>> Kathleen
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 16 Feb 2015 23:42:30 +0000

A few responses and comments are inline below...

> From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt
> Sent: Thursday, February 12, 2015 11:47 AM
> To: Justin Richer
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
>
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
> [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?

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

HTTP Basic is set to the default because that's the default in RFC 6749 and this specification is about registering clients for use with RFC 6749.  Trying to change the RFC 6749 default really isn't within the scope of this work.  (If that's done, it should probably be done in an http6749-bis spec.)  However, the spec does define a registry that new methods like HOBA can be registered in when people want to use them.  (And if HOBA finishes before Dynamic Registration, I'm fine adding a registry entry for it in this spec.)

If you're interested in the client_secret_jwt and private_key_jwt client authentication methods that Justin alluded to, these are defined in Section 9 of OpenID Connect Core http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication.

In relation to your internationalization comments Kathleen, note that Section 2.3.1 of RFC 6749 explicitly provides a mechanism for encoding international strings for use with HTTP Basic.  This was added under the supervision of Julian Reschke, I believe as a result of his WGLC comments.  So whether this is the same as what the new version of HTTP Basic does or not, OAuth 2.0 already does provide a standard way to use internationalized strings with HTTP Basic for OAuth client authentication.

> 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 [email-masked])?
>

We should probably say that in the draft then.

> [Phil]
> I've added some more explanatory text. Note...some of this may be better put elsewhere.
>
>       instances of software, the "software_id" SHOULD remain the same for all client software
>       instances. The "software_id" SHOULD remain the same across multiple software updates
>       or versions.

I'd revise the last two sentences of this as follows:

      Unlike "client_id", which is issued by the authorization server and may vary between
      instances of a piece of software, the "software_id" SHOULD remain the same for all instances
      of a piece of software. The "software_id" SHOULD remain the same across multiple software updates
      or versions of the same piece of software.

> software_version
>       A version identifier for the software identified by "software_id".  The
>       using string equality matching. Unlike "software_id", the value of the
>       software. A service provider MAY use "software_id" and "software_version" to

Justin, do you want to make specific rewording proposals for this and the other editorial issues that were identified?

				Thanks all,
				-- Mike

---

From: Justin Richer <[email-masked]>
Date: Mon, 16 Feb 2015 19:43:29 -0500

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

---

From: Phil Hunt <[email-masked]>
Date: Tue, 17 Feb 2015 16:03:04 -0800

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
[email-masked]

> On Feb 16, 2015, at 4:43 PM, Justin Richer <[email-masked]> 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
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 18 Feb 2015 08:51:53 -0500

Hi,

On Tue, Feb 17, 2015 at 7:03 PM, Phil Hunt <[email-masked]> 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

Thank you,
Kathleen

> 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
> >
> let the other authors talk about their sections (deployment org, software
> version, etc) directly.
> >>>
> 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
> 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:
> >> 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:
> >>>
> as the default and add that to the draft?  Section 2.3.1 of OAuth 2.0 just
> 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.
> >>>
> 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?).
> >> HTTP Basic is set to the default because that's the default in RFC 6749
> and this specification is about registering clients for use with RFC 6749.
> Trying to change the RFC 6749 default really isn't within the scope of this
> work.  (If that's done, it should probably be done in an http6749-bis
> spec.)  However, the spec does define a registry that new methods like HOBA
> can be registered in when people want to use them.  (And if HOBA finishes
> before Dynamic Registration, I'm fine adding a registry entry for it in
> this spec.)
> >>
> >> If you're interested in the client_secret_jwt and private_key_jwt
> client authentication methods that Justin alluded to, these are defined in
> Section 9 of OpenID Connect Core
> http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication.
> >>
> >> In relation to your internationalization comments Kathleen, note that
> Section 2.3.1 of RFC 6749 explicitly provides a mechanism for encoding
> international strings for use with HTTP Basic.  This was added under the
> supervision of Julian Reschke, I believe as a result of his WGLC comments.
> So whether this is the same as what the new version of HTTP Basic does or
> not, OAuth 2.0 already does provide a standard way to use internationalized
> strings with HTTP Basic for OAuth client authentication.
> >>
> >>> Section 2: Contacts:
> >>>
> >>> 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.
> >>>
> >>>
> >>>
> are several specifications on software_id (and platform).  Does consistency
> readable, should the above be in the list?  I would expect this list to be
> software_version are not intended to be human readable and don't need the
> multi-language support]
> so no worries there. The ID represents an individual piece of software, not
> a person, though if that person is the sole user of the instance of
> considerations that we should point that out. However, dynamic registration
> can actually help mitigate this as well, since in the normal case (with no
> software statements) there's no way to correlate instances of clients with
> each other.
> >>>
> >>> Nothing gathered about the user during registration, as this happens
> in the back channel outside the user's purview.
> >>>
> personal details that may be considered sensitive)?  I don't think this was
> covered in the OAuth 2.0 RFC.
> implementation of the authorization server, and I'm not really sure how (or
> if) to address them in this draft. Any suggestions would be welcomed here.
> >>>
> >>> I think it was less onerous of a repeat when both simply said "use
> TLS", so some refactoring after the expansion of the text makes sense to
> me. Would it be better to have it upfront in the endpoint definition, or in
> >> Justin, do you want to make specific rewording proposals for this and
> the other editorial issues that were identified?
> >>
> >>> --
> >>>
> >>> Best regards,
> >>> Kathleen
> >>>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 18 Feb 2015 09:46:07 -0500

Hi,

> let the other authors talk about their sections (deployment org, software

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

> > [Phil] Agreed with Kathleen's suggestion.
Thanks!

> mechanisms as a separate draft or an eventual update to RFC6749 (or both?).

A separate draft is fine and I'd like the WG to think about what more
secure options for authentication would be best to add in that draft and
into the registry.  With the popularity of Oauth, I think we could and
should be creating better options.

> Yep, I get this and stated I understood why this was the case in my
original message. I suggested HOBA because it is already in the RFC editor
queue, approved by the IESG.  The WG should discuss this and see how they
want to proceed.

If you're interested in the client_secret_jwt and private_key_jwt client
> authentication methods that Justin alluded to, these are defined in Section
> 9 of OpenID Connect Core

I'll take a look, thanks.

> strings with HTTP Basic for OAuth client authentication.
The new version of Basic cleans up Internationalization concerns and adds
text to say how bad the security problems of basic are.  That's all I was
saying, I was not asking for you to update anything in this draft except to
see if the updated version of HTTP Basic should be used.  It's backwards
compatible and still horribly insecure, not to worry.  It's on this week's
teelchat, so it is ahead of this draft in the queue.

> guidelines for this new section.

I don't care about the length argument, I think someone else else had a
more reasonable explanation of why this should be left out and I was okay
with that.  At least a pointer would be good to the privacy section so
folks know to look at it.  I had the questions as soon as I read this text
and had to wait until the very end to see an answer, it would be good for
folks who don't know this is an issue to have the pointer.

> We should probably say that in the draft then.

Are there specific well-known formats that should be used?  If it's machine
parseable, how does one know which format is expected?  If it's just the
label sent by the application, then expect variance and issues as each
version might not be in a consistent format.  If it is a formatted
description like SWID, then that should be stated or if a mix of formats
are fine with no preference.

> software statements) there's no way to correlate instances of clients with

OK, can someone propose text?

> the back channel outside the user's purview.

OK, please make that clear in the privacy considerations section.

> 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 first paragraph is a repeat of text.  Can this just be in one place
> and use a pointer to the full text?  I like the requirement, but reading it
> once is enough.
> >
> Would it be better to have it upfront in the endpoint definition, or in the
> security considerations?
>

I'd put it int he security considerations and just have a pointer from the
earlier text so references are all in one place.

Thank you,
Kathleen

>
> Justin, do you want to make specific rewording proposals for this and the
> other editorial issues that were identified?
>
> > --
> >
> > Best regards,
> > Kathleen
> >

-- 

Best regards,
Kathleen

---

From: John Bradley <[email-masked]>
Date: Wed, 18 Feb 2015 07:07:57 -0800

snip
> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> 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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 18 Feb 2015 10:30:20 -0500

On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <[email-masked]> wrote:

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

-- 

Best regards,
Kathleen

---

From: Justin Richer <[email-masked]>
Date: Wed, 18 Feb 2015 12:37:55 -0500

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 <[email-masked]> wrote:
> 
> 
> 
> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> snip
>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> Thanks, John.  It may be helpful to add in this explanation unless there is some reason not to? 
> 
> John B.
> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Feb 2015 18:57:57 +0100

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:
>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>>>     <[email-masked]
>>>     <mailto:[email-masked]>> wrote:
>>>
>>>     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. 
>>
>>     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.
>>
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Feb 2015 18:57:57 +0100

Hi Justin, Hi John,

Ciao
Hannes

---

From: Sam Hartman <[email-masked]>
Date: Wed, 18 Feb 2015 16:45:06 -0500

>>>>> "Kathleen" == Kathleen Moriarty <[email-masked]> 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

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 18 Feb 2015 17:02:37 -0500

> 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

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Feb 2015 18:07:44 -0500

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 <
[email-masked]> 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.
> >>>
> >>>

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Tue, 24 Feb 2015 23:47:54 +0000

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:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Tuesday, February 24, 2015 3:08 PM
To: Hannes Tschofenig
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Justin, Hi John,

Ciao
Hannes

On 02/18/2015 06:37 PM, Justin Richer wrote:
>> <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>>
>>
>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>>     snip
>>>     <[email-masked]<mailto:[email-masked]>
>>>     <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>
>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Feb 2015 18:53:55 -0500

Hi Mike,

On Tue, Feb 24, 2015 at 6:47 PM, Mike Jones <[email-masked]>
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.
>
>
>

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:[email-masked]] *On Behalf Of *Kathleen
> Moriarty
> *Sent:* Tuesday, February 24, 2015 3:08 PM
> *To:* Hannes Tschofenig
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
>
>
>
> Hello,
>
>
>

-- 

Best regards,
Kathleen

---

From: Bill Burke <[email-masked]>
Date: Tue, 24 Feb 2015 18:59:03 -0500

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:
> 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
> 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.
>
> *From:*OAuth [mailto:[email-masked]] *On Behalf Of *Kathleen
> Moriarty
> 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.
>
> 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
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Hi Justin, Hi John,
>
> <mailto:[email-masked]>
>  >> <mailto:[email-masked]
> <mailto:[email-masked]>>> wrote:
>  >>
>  >>
>  >>
>  >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>  >>
>  >>     snip
> <mailto:[email-masked]>
>  >>>     <mailto:[email-masked]
> <mailto:[email-masked]>>> wrote:
>  >>>
>  >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>

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

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Feb 2015 00:28:24 +0000

Not that I'm aware of.

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Bill Burke
Sent: Tuesday, February 24, 2015 3:59 PM
To: [email-masked]
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 - 
> 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 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.
>
> 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
>
>  > 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  >> 
>  >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <[email-masked] 
> <mailto:[email-masked]>  >> <mailto:[email-masked] 
> <mailto:[email-masked]>>> wrote:
>  >>
>  >>     snip
> 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.
>  >>>
>  >>>
>  >>     rotations, so it wouldn't really achieve anything.
>  >>
>  >>     One thing we don't do is allow the client to specify the
>  >>     multiple AS and that might be a privacy issue, but we don't
> allow it.
>  >>
>  >>
> <mailto:[email-masked]>>  >> 
>  > [email-masked] <mailto:[email-masked]>  >

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Feb 2015 20:02:01 -0500

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 <[email-masked]> wrote:
> 
> On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig <[email-masked]> wrote:
> Hi Justin, Hi John,
> 
> >> <mailto:[email-masked]>> wrote:
> >>
> >>     snip

---

From: John Bradley <[email-masked]>
Date: Tue, 24 Feb 2015 20:55:04 -0500

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 <[email-masked]> wrote:
> 
> Hi Justin, Hi John,
>

---

From: John Bradley <[email-masked]>
Date: Tue, 24 Feb 2015 21:03:27 -0500

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 <[email-masked]> wrote:
> 
> On Feb 24, 2015, at 6:47 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> 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:
>>  
>> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Kathleen Moriarty
>> Cc: [email-masked] <mailto:[email-masked]>
>> On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Justin, Hi John,
>> 
>> >> <[email-masked] <mailto:[email-masked]>
>> >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> >>
>> >>
>> >>
>> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <[email-masked] <mailto:[email-masked]>
>> >>>     <[email-masked] <mailto:[email-masked]>
>> >>>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> >>>
>> >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Feb 2015 22:20:51 -0500

Thanks, John!

Sent from my iPhone

> On Feb 24, 2015, at 9:03 PM, John Bradley <[email-masked]> 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:
>>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 25 Feb 2015 11:23:45 -0500

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 <[email-masked]> wrote:
>