Subject: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances)

From: Phil Hunt <[email-masked]>
Date: Wed, 22 May 2013 12:59:14 -0700

I had a conversation with Justin yesterday to try to come to a resolution regarding my concerns about client instances and being able to associate client instances that are issued for the same client software. I think we made some progress.

Background:  
In RFC6749, public clients, had a common client_id. Many interpreted client_id as refering to the client application software (e.g. the iPhone Facebook app). This is probably due to the types of OAuth2 implementations that existed at the time, where there was a single SP instance.  Others have interpreted that client_id does not refer to client applications but rather ideally should point to instances of software. To me this seems like equating a client_id to being a user-id -- IOW the key part of a credential rather than a client identifier. 

The new draft proposes that each instance be identified separately. However it does so without keeping track of client software that is the same.

Never-the-less, I think both interpretations can be accommodated.

Finally, in single instance services (like Facebook, Twitter, etc), there was a natural registration and approval cycle bound into the client_id issuance process. The developer was able to talk to the single service provider and obtain a client_id for all deployments. It wasn't stated, but the client_id registration sites served a useful way to do application approvals.  This is a difficult problem to solve when there are multiple instance of Resource API deployed in multiple locations. The developer can't contact them all.  Further, because the current draft loses knowledge of how to recognize that two instances of clients share the same software, there's no ability to have an approval process. Each instance is essentially anonymous, and thus approval processes would not be possible.  Though it does not require it, this proposal makes it possible for service providers to recognize new software and to have approval process.

Proposal:
What I have worked out with Justin (and he may not yet fully agree with everything) is a proposal that solves the problem in an optional way that will not break existing clients. 

I also propose that optional version numbers also be supported. This is useful to service providers who need to know which client_ids are affected when certain software clients and/or versions are deprecated. The re-introduction of the renamed software_id further enables "local" registration to occur. The first time a client tries to register, a service provider could for example, choose to hold the registration to obtain administrative approval.

The solution here is not intended to provide software "authentication" or software verification. The solution simply allows service providers to make pragmatic decisions about sets of clients that typically work the same way in a change managed environment. 

Question:  What happens if the server does not support these new parameters and the client provides them?  The current draft already covers this in Section 3.  Specifically:
>  The Client Registration Endpoint MUST ignore all parameters it does not understand.

Below are 3 options for the group to consider.  My recommendation is for option 1. My concern is option 2 will lead to complexity because clients and service providers will attempt to encode versions and software identifiers into one field. I would rather keep this to simple UUIDs for most cases.

Option 1 (2 parameters):

software_id
This value MAY be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code. The identifier SHOULD NOT change between software updates. While a client application MAY be issued multiple client_id's and client credentials over its deployment lifecycle, the software_id SHOULD NOT change.

Signed assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.

[editorial note: some current deployments are using temporary client credential assertions for this purpose. I propose to standardize this in this field since an assertion would server the same purpose as a UUID only providing third party signing and other claims. I am concerned that passing a client assertion for this purpose creates complexity in client authentication processing - though obviously Justin has it working]

software_version
RECOMMENDED. A version indicates a client developer chosen version number. The identifier SHOULD BE the same across all copies of client software. The version number SHOULD change between different client updates. The intention is that Service Providers MAY perform equality matching with software_id to sub-select groups of clients of a particular software version.

Option 2 (single parameter):

software_id
This value MAY be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code. The identifier SHOULD change when the client software has changed such as with a version update or a platform change.

Signed assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.

[note: same editorial note as option 1]

Option 3 (no change):

In this option, no changes to the draft are made. 

Personal comment:  It has been proposed by several on the list that another extension draft be written for these features as an extension to the dynamic registration draft. In my opinion, such a draft would be very small in size without clear reason for separation. My feeling is that some technical justification for keeping these features separated will likely be needed.

Phil

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

---

From: John Bradley <[email-masked]>
Date: Wed, 22 May 2013 17:20:44 -0400

Phil,

As I pointed out in the other thread,  redirect_uri is the thing that ties together the clients as that is the place the responses need to go to so is hard to fake.

All instances of a particular client application will share the same redirect_uri across all instances.   

Adding a bunch of self asserted informational fields to the base spec is not really helping.  In a enterprise situation where all the apps play nice it might be helpfull but the reality is that you probably allready have a MDM that lets you manage app versions.

John 

On 2013-05-22, at 3:59 PM, Phil Hunt <[email-masked]> wrote:

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

---

From: Mike Jones <[email-masked]>
Date: Wed, 22 May 2013 21:27:01 +0000

+1

We already have a "software_id" field and it's named "redirect_uris".

This doesn't seem well thought-out.  We shouldn't try to jam it into the spec at the last minute.

The good news is that since the registration spec allows for extensions, and the proposed fields are optional, these could be added later as a non-breaking change by another spec if the working group eventually decides to pursue a route like the one proposed below.  We don't have to do it now for this to eventually come into being after deliberate consideration of a complete specification including these features by the working group.

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, May 22, 2013 2:21 PM
To: Phil Hunt
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances)

Phil,

John

On 2013-05-22, at 3:59 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Background:

Proposal:

Option 1 (2 parameters):

software_id

software_version

software_id

Option 3 (no change):

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

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

---

From: prateek mishra <[email-masked]>
Date: Wed, 22 May 2013 18:00:27 -0400

Well, I have to say that if anything seems poorly thought out, it would 
be a design with the following characteristics.

[quote]
We already have a "software_id" field and it's named "redirect_uris"
[\quote]

This seems to violate the most basic principles of software design - 
overloading a field with meaning distinct from its primary purpose!!

Phil has raised some substantive questions regarding client meta-data 
and the registration process. This information (software_id) is
essential for identifying and disabling a class of clients that may have 
been found to have some security flaws, for example.
This is a practical deployment issue that also impacts the security 
characteristics of OAuth.  It should be taken into account in the client 
registration process.

I hope we will take the time to discuss this issue carefully and not 
rush  to finalize a specification which has NOT received much review
from the OAuth community.

- prateek

> The good news is that since the registration spec allows for 
> extensions, and the proposed fields are optional, these could be added 
> later as a non-breaking change by another spec if the working group 
> eventually decides to pursue a route like the one proposed below.  We 
> don't have to do it now for this to eventually come into being after 
> deliberate consideration of a complete specification including these 
> features by the working group.
>
> -- Mike
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *John Bradley
> *Sent:* Wednesday, May 22, 2013 2:21 PM
> *To:* Phil Hunt
> *Cc:* [email-masked] WG
> *Subject:* Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to 
> client_id definition issue (was: Client Instances)
>
> Phil,
>
> As I pointed out in the other thread,  redirect_uri is the thing that 
> ties together the clients as that is the place the responses need to 
> go to so is hard to fake.
>
> Adding a bunch of self asserted informational fields to the base spec 
> is not really helping.  In a enterprise situation where all the apps 
> play nice it might be helpfull but the reality is that you probably 
> allready have a MDM that lets you manage app versions.
>
> John
>
> I had a conversation with Justin yesterday to try to come to a 
> resolution regarding my concerns about client instances and being able 
> to associate client instances that are issued for the same client 
> software. I think we made some progress.
>
> */Background: /*
>
> In RFC6749, public clients, had a common client_id. Many interpreted 
> client_id as refering to the client application software (e.g. the 
> iPhone Facebook app). This is probably due to the types of OAuth2 
> implementations that existed at the time, where there was a single SP 
> instance.  Others have interpreted that client_id does not refer to 
> client applications but rather ideally should point to instances of 
> software. To me this seems like equating a client_id to being a 
> user-id -- IOW the key part of a credential rather than a client 
> identifier.
>
> The new draft proposes that each instance be identified separately. 
> However it does so without keeping track of client software that is 
> the same.
>
> Finally, in single instance services (like Facebook, Twitter, etc), 
> there was a natural registration and approval cycle bound into the 
> client_id issuance process. The developer was able to talk to the 
> single service provider and obtain a client_id for all deployments. It 
> wasn't stated, but the client_id registration sites served a useful 
> way to do application approvals.  This is a difficult problem to solve 
> when there are multiple instance of Resource API deployed in multiple 
> locations. The developer can't contact them all.  Further, because the 
> current draft loses knowledge of how to recognize that two instances 
> of clients share the same software, there's no ability to have an 
> approval process. Each instance is essentially anonymous, and thus 
> approval processes would not be possible.  Though it does not require 
> it, this proposal makes it possible for service providers to recognize 
> new software and to have approval process.
>
> */Proposal:/*
>
> What I have worked out with Justin (and he may not yet fully agree 
> with everything) is a proposal that solves the problem in an optional 
> way that will not break existing clients.
>
> I also propose that optional version numbers also be supported. This 
> is useful to service providers who need to know which client_ids are 
> affected when certain software clients and/or versions are deprecated. 
> The re-introduction of the renamed software_id further enables "local" 
> registration to occur. The first time a client tries to register, a 
> service provider could for example, choose to hold the registration to 
> obtain administrative approval.
>
> The solution here is not intended to provide software "authentication" 
> or software verification. The solution simply allows service providers 
> to make pragmatic decisions about sets of clients that typically work 
> the same way in a change managed environment.
>
> Question:  What happens if the server does not support these new 
> parameters and the client provides them?  The current draft already 
> covers this in Section 3.  Specifically:
>
> Below are 3 options for the group to consider.  My recommendation is 
> for option 1. My concern is option 2 will lead to complexity because 
> clients and service providers will attempt to encode versions and 
> software identifiers into one field. I would rather keep this to 
> simple UUIDs for most cases.
>
> *Option 1 (2 parameters):*
>
> software_id
>
> This value MAY be required by registration endpoints. The value MAY be 
> a unique identifier (UUID) self-assigned by a the client application 
> developer, or it MAY be an assertion. The value SHOULD be the same 
> across all instances of a client on an application platform. For 
> example, software used in a mobile phone should be considered as 
> different from a web server implementation though it may share the 
> same code.The identifier *SHOULD NOT *change between software 
> updates. While a client application MAY be issued multiple client_id's 
> and client credentials over its deployment lifecycle, the software_id 
> SHOULD NOT change.
>
> Signed assertions MAY be used as software identifiers to allow 
> different dynamic registration end-points to recognize approval from a 
> common issuer (for example in cases where the resource API released by 
> a single publisher but deployed in many different domains). The 
> decision to use assertions and the method by which developers know how 
> to obtain assertions is out of scope for this specification.
>
> [editorial note: some current deployments are using temporary client 
> credential assertions for this purpose. I propose to standardize this 
> in this field since an assertion would server the same purpose as a 
> UUID only providing third party signing and other claims. I am 
> concerned that passing a client assertion for this purpose creates 
> complexity in client authentication processing - though obviously 
> Justin has it working]
>
> software_version
>
> RECOMMENDED. A version indicates a client developer chosen version 
> number. The identifier SHOULD BE the same across all copies of client 
> software. The version number SHOULD change between different client 
> updates. The intention is that Service Providers MAY perform equality 
> matching with software_id to sub-select groups of clients of a 
> particular software version.
>
> *Option 2 (single parameter):*
>
> software_id
>
> This value MAY be required by registration endpoints. The value MAY be 
> a unique identifier (UUID) self-assigned by a the client application 
> developer, or it MAY be an assertion. The value SHOULD be the same 
> across all instances of a client on an application platform. For 
> example, software used in a mobile phone should be considered as 
> different from a web server implementation though it may share the 
> same code. The identifier *SHOULD* change when the client software has 
> changed such as with a version update or a platform change.
>
> Signed assertions MAY be used as software identifiers to allow 
> different dynamic registration end-points to recognize approval from a 
> common issuer (for example in cases where the resource API released by 
> a single publisher but deployed in many different domains). The 
> decision to use assertions and the method by which developers know how 
> to obtain assertions is out of scope for this specification.
>
> *Option 3 (no change):*
> Personal comment:  It has been proposed by several on the list that 
> another extension draft be written for these features as an extension 
> to the dynamic registration draft. In my opinion, such a draft would 
> be very small in size without clear reason for separation. My feeling 
> is that some technical justification for keeping these features 
> separated will likely be needed.
>
> Phil
>
> @independentid
>
> www.independentid.com <http://www.independentid.com/>
>
> [email-masked] <mailto:[email-masked]>
>
>
>
> [email-masked] <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Wed, 22 May 2013 18:15:53 -0400

At the moment for Mobile devices and other native apps all we have to reliably identify the app is the redirect_uri.  

The client_id is trivially faked in native apps. 

Yes in a well groomed enterprise trusting a self asserted software identifier is nice but probably doesn't scale to the real world.

I have had discussions with MDM venders about how you might be able to tie access tokens to a instance of software on a device and determine if that software is allowed to be run by that user on that device.
These are all much more complicated discussions than just sticking another registration parameter on.

I don't think this should block the basic dynamic registration spec.   App lifecycle needs a full spec, and additional registration parameters can be added later if required.

I am not insensitive to the problem.

John B.
On 2013-05-22, at 6:00 PM, prateek mishra <[email-masked]> wrote:

> Well, I have to say that if anything seems poorly thought out, it would be a design with the following characteristics.
> 
> [quote]
> We already have a “software_id” field and it’s named “redirect_uris”
> [\quote]
> 
> This seems to violate the most basic principles of software design - overloading a field with meaning distinct from its primary purpose!!
> 
> Phil has raised some substantive questions regarding client meta-data and the registration process. This information (software_id) is
> essential for identifying and disabling a class of clients that may have been found to have some security flaws, for example. 
> This is a practical deployment issue that also impacts the security characteristics of OAuth.  It should be taken into account in the client registration process. 
> 
> I hope we will take the time to discuss this issue carefully and not rush  to finalize a specification which has NOT received much review
>> We already have a “software_id” field and it’s named “redirect_uris”.
>>  
>> This doesn’t seem well thought-out.  We shouldn’t try to jam it into the spec at the last minute.
>>  
>> The good news is that since the registration spec allows for extensions, and the proposed fields are optional, these could be added later as a non-breaking change by another spec if the working group eventually decides to pursue a route like the one proposed below.  We don’t have to do it now for this to eventually come into being after deliberate consideration of a complete specification including these features by the working group.
>>  
>>                                                                 -- Mike
>>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 22 May 2013 15:19:32 -0700

I dont see a big issue with a faked software_id. As i said it was a minimal proposal with the door open to stronger assertions. 

Rogue clients pretending to be something they are not is actually more evidence of a problem. In draft 10 you cant even do that. 

Phil

---

From: Justin Richer <[email-masked]>
Date: Wed, 22 May 2013 18:21:38 -0400

There are two main things that I dislike about this proposal, but 
neither are insurmountable in my view.

1) Version. I think that the entire notion of "version" is as slippery a 
slope as "software identifier" is in the first place. And as soon as you 
start talking about "version" people are going to want to do linear 
comparisons, to say things like "version > 3.1.0" and not just "version 
== 3.1.0, 3.1.1, 3.1.2, ...". I would suggest dropping version all together.

2) Assertions. I think that if you're going to do assertions, do them as 
part of the the initial registration request's authorization (via an 
OAuth token). That's exactly the kind of thing that the oauth-token 
functionality was put there for, and we don't need to conflate this with 
the software identifier. I would suggest not mentioning assertions at 
all. If you want to tie down things like software_id (or redirect_uri, 
or anything else), you'll need to specify other things in order to do it 
in an interoperable way, like how to format or parse the assertion or 
how to call a discovery service to correlate things.

So if this were to go in, I would rather see it like this (Option 4):

software_id
The value an identifier for the client software being registered. It is 
RECOMMENDED that clients send this value to help Authorization Servers 
facilitate client management. The content and structure of this value 
are out of scope for this specification, and as all Client Metadata is 
assumed to be self-asserted the Authorization Server MUST NOT make any 
security decisions based on the value of this field alone. This field 
MAY be a random value (such as a UUID) self-assigned by the client 
application developer or it may be supplied by another party. The value 
SHOULD be the same across all instances of a client on an application 
platform. For example, software used in a mobile phone should be 
considered as different from a web server implementation though it may 
share the same code.While a client application MAY be issued multiple 
client_id's and client credentials over its deployment lifecycle, the 
software_id SHOULD NOT change.

While I don't think it gives you *real* hooks without specifying ways to 
verify and validate the value in this field, and I don't think such 
mechanisms belong in this spec, I don't think that adding this field 
hurts much.

On the same token, I'm not convinced it's worth it, but if Phil, 
Prateek, and others thing that this would provide enough of a hook for 
what they want to do without breaking existing extensions and profiles 
of Dyn Reg (clients don't have to send it, servers can ignore it) that 
we could actually unstick this issue and move things forward.

I think that the *real* work is still ahead of us with regard to 
instance management, as I think there's a lot more to this particular 
nut to be cracked that can be solved better in its own specification.

  -- Justin

On 05/22/2013 03:59 PM, Phil Hunt wrote:
> www.independentid.com <http://www.independentid.com>

---

From: Justin Richer <[email-masked]>
Date: Wed, 22 May 2013 18:47:08 -0400

I agree with Prateek that redirect_uri isn't sufficient or well-suited 
for this, but I also agree with John that software_id on its own doesn't 
buy you a whole lot as a standalone field. It could be a reasonable 
stepping stone to future, more high-assurance work, but my question is 
then: is it really worth it to define a field now when the real work 
will come later? Why not just define the field then and make it fit better?

  -- Justin

On 05/22/2013 06:19 PM, Phil Hunt wrote:
> I dont see a big issue with a faked software_id. As i said it was a 
> minimal proposal with the door open to stronger assertions.
>
> Rogue clients pretending to be something they are not is actually more 
> evidence of a problem. In draft 10 you cant even do that.
>
> Phil
>
> On 2013-05-22, at 15:15, John Bradley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> At the moment for Mobile devices and other native apps all we have to 
>> reliably identify the app is the redirect_uri.
>>
>> Yes in a well groomed enterprise trusting a self asserted software 
>> identifier is nice but probably doesn't scale to the real world.
>>
>> I have had discussions with MDM venders about how you might be able 
>> to tie access tokens to a instance of software on a device and 
>> determine if that software is allowed to be run by that user on that 
>> device.
>> I don't think this should block the basic dynamic registration spec. 
>>   App lifecycle needs a full spec, and additional registration 
>> parameters can be added later if required.
>>
>> On 2013-05-22, at 6:00 PM, prateek mishra <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> Well, I have to say that if anything seems poorly thought out, it 
>>> would be a design with the following characteristics.
>>>
>>> [quote]
>>> Phil has raised some substantive questions regarding client 
>>> meta-data and the registration process. This information 
>>> (software_id) is
>>> essential for identifying and disabling a class of clients that may 
>>> have been found to have some security flaws, for example.
>>> characteristics of OAuth.  It should be taken into account in the 
>>> client registration process.
>>>
>>>> extensions, and the proposed fields are optional, these could be 
>>>> added later as a non-breaking change by another spec if the working 
>>>> group eventually decides to pursue a route like the one proposed 
>>>> below.  We don't have to do it now for this to eventually come into 
>>>> being after deliberate consideration of a complete specification 
>>>> including these features by the working group.
>>>>
>>>> -- Mike
>>>>
>>>> *Subject:* Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix 
>>>> to client_id definition issue (was: Client Instances)
>>>>
>>>> Phil,
>>>>
>>>> As I pointed out in the other thread,  redirect_uri is the thing 
>>>> that ties together the clients as that is the place the responses 
>>>> need to go to so is hard to fake.
>>>>
>>>> Adding a bunch of self asserted informational fields to the base 
>>>> spec is not really helping.  In a enterprise situation where all 
>>>> the apps play nice it might be helpfull but the reality is that you 
>>>> probably allready have a MDM that lets you manage app versions.
>>>>
>>>> John
>>>>
>>>> resolution regarding my concerns about client instances and being 
>>>> able to associate client instances that are issued for the same 
>>>> client software. I think we made some progress.
>>>>
>>>> */Background: /*
>>>>
>>>> In RFC6749, public clients, had a common client_id. Many 
>>>> interpreted client_id as refering to the client application 
>>>> software (e.g. the iPhone Facebook app). This is probably due to 
>>>> the types of OAuth2 implementations that existed at the time, where 
>>>> there was a single SP instance.  Others have interpreted that 
>>>> client_id does not refer to client applications but rather ideally 
>>>> should point to instances of software. To me this seems like 
>>>> equating a client_id to being a user-id -- IOW the key part of a 
>>>> credential rather than a client identifier.
>>>>
>>>> single service provider and obtain a client_id for all deployments. 
>>>> It wasn't stated, but the client_id registration sites served a 
>>>> useful way to do application approvals.  This is a difficult 
>>>> problem to solve when there are multiple instance of Resource API 
>>>> deployed in multiple locations. The developer can't contact them 
>>>> all.  Further, because the current draft loses knowledge of how to 
>>>> recognize that two instances of clients share the same software, 
>>>> there's no ability to have an approval process. Each instance is 
>>>> essentially anonymous, and thus approval processes would not be 
>>>> possible.  Though it does not require it, this proposal makes it 
>>>> possible for service providers to recognize new software and to 
>>>> have approval process.
>>>>
>>>> */Proposal:/*
>>>>
>>>> with everything) is a proposal that solves the problem in an 
>>>> optional way that will not break existing clients.
>>>>
>>>> I also propose that optional version numbers also be supported. 
>>>> This is useful to service providers who need to know which 
>>>> client_ids are affected when certain software clients and/or 
>>>> versions are deprecated. The re-introduction of the renamed 
>>>> software_id further enables "local" registration to occur. The 
>>>> first time a client tries to register, a service provider could for 
>>>> example, choose to hold the registration to obtain administrative 
>>>> approval.
>>>>
>>>> The solution here is not intended to provide software 
>>>> "authentication" or software verification. The solution simply 
>>>> allows service providers to make pragmatic decisions about sets of 
>>>> clients that typically work the same way in a change managed 
>>>> environment.
>>>>
>>>> Below are 3 options for the group to consider.  My recommendation 
>>>> is for option 1. My concern is option 2 will lead to complexity 
>>>> because clients and service providers will attempt to encode 
>>>> versions and software identifiers into one field. I would rather 
>>>> keep this to simple UUIDs for most cases.
>>>>
>>>> This value MAY be required by registration endpoints. The value MAY 
>>>> be a unique identifier (UUID) self-assigned by a the client 
>>>> application developer, or it MAY be an assertion. The value SHOULD 
>>>> be the same across all instances of a client on an application 
>>>> considered as different from a web server implementation though it 
>>>> may share the same code.The identifier *SHOULD NOT *change between 
>>>> software updates. While a client application MAY be issued multiple 
>>>> client_id's and client credentials over its deployment lifecycle, 
>>>> the software_id SHOULD NOT change.
>>>>
>>>> different dynamic registration end-points to recognize approval 
>>>> from a common issuer (for example in cases where the resource API 
>>>> released by a single publisher but deployed in many different 
>>>> domains). The decision to use assertions and the method by which 
>>>> developers know how to obtain assertions is out of scope for this 
>>>> specification.
>>>>
>>>> [editorial note: some current deployments are using temporary 
>>>> client credential assertions for this purpose. I propose to 
>>>> standardize this in this field since an assertion would server the 
>>>> same purpose as a UUID only providing third party signing and other 
>>>> claims. I am concerned that passing a client assertion for this 
>>>> purpose creates complexity in client authentication processing - 
>>>> though obviously Justin has it working]
>>>>
>>>> software_version
>>>>
>>>> number. The identifier SHOULD BE the same across all copies of 
>>>> client software. The version number SHOULD change between different 
>>>> client updates. The intention is that Service Providers MAY perform 
>>>> equality matching with software_id to sub-select groups of clients 
>>>> of a particular software version.
>>>>
>>>> This value MAY be required by registration endpoints. The value MAY 
>>>> be a unique identifier (UUID) self-assigned by a the client 
>>>> application developer, or it MAY be an assertion. The value SHOULD 
>>>> be the same across all instances of a client on an application 
>>>> considered as different from a web server implementation though it 
>>>> may share the same code. The identifier *SHOULD* change when the 
>>>> client software has changed such as with a version update or a 
>>>> platform change.
>>>>
>>>> different dynamic registration end-points to recognize approval 
>>>> from a common issuer (for example in cases where the resource API 
>>>> released by a single publisher but deployed in many different 
>>>> domains). The decision to use assertions and the method by which 
>>>> developers know how to obtain assertions is out of scope for this 
>>>> specification.
>>>>
>>>> another extension draft be written for these features as an 
>>>> extension to the dynamic registration draft. In my opinion, such a 
>>>> draft would be very small in size without clear reason for 
>>>> separation. My feeling is that some technical justification for 
>>>> keeping these features separated will likely be needed.
>>>>
>>>> Phil
>>>>
>>>> @independentid
>>>>

---

From: Mike Jones <[email-masked]>
Date: Wed, 22 May 2013 22:56:36 +0000

I agree that any new field or fields should be defined once the requirements and flows are well-specified and well-understood as part of a complete specification for those flows and use cases.

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Wednesday, May 22, 2013 3:47 PM
To: Phil Hunt
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances)

I agree with Prateek that redirect_uri isn't sufficient or well-suited for this, but I also agree with John that software_id on its own doesn't buy you a whole lot as a standalone field. It could be a reasonable stepping stone to future, more high-assurance work, but my question is then: is it really worth it to define a field now when the real work will come later? Why not just define the field then and make it fit better?

 -- Justin

Phil

On 2013-05-22, at 15:15, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
At the moment for Mobile devices and other native apps all we have to reliably identify the app is the redirect_uri.

John B.
On 2013-05-22, at 6:00 PM, prateek mishra <[email-masked]<mailto:[email-masked]>> wrote:

[quote]

- prateek

+1

                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, May 22, 2013 2:21 PM
To: Phil Hunt
Cc: [email-masked]<mailto:[email-masked]> WG
Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances)

Phil,

John

Background:

Proposal:

Option 1 (2 parameters):

software_id

software_version

software_id

Option 3 (no change):

Phil

@independentid

OAuth mailing list

OAuth mailing list

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 23 May 2013 07:58:26 +0900

It is not worth defining it now. It actually is harmful.
I can see developers start trusting the identifier and causing problems
later.
We should do it together with more thought out security measures.

2013/5/23 Justin Richer <[email-masked]>

> then: is it really worth it to define a field now when the real work will
> come later? Why not just define the field then and make it fit better?
>
>  -- Justin
>
>
>  I have had discussions with MDM venders about how you might be able to
> tie access tokens to a instance of software on a device and determine if
> that software is allowed to be run by that user on that device.
> App lifecycle needs a full spec, and additional registration parameters can
> be added later if required.
>
> Phil has raised some substantive questions regarding client meta-data and
> the registration process. This information (software_id) is
> I hope we will take the time to discuss this issue carefully and not rush
> to finalize a specification which has NOT received much review
>  +1****
> We already have a “software_id” field and it’s named “redirect_uris”.****
>
>
>
> This doesn’t seem well thought-out.  We shouldn’t try to jam it into the
> spec at the last minute.****
>
>
>
> The good news is that since the registration spec allows for extensions,
> and the proposed fields are optional, these could be added later as a
> non-breaking change by another spec if the working group eventually decides
> to pursue a route like the one proposed below.  We don’t have to do it now
> for this to eventually come into being after deliberate consideration of a
> complete specification including these features by the working group.****
>
>
>
>                                                                 -- Mike***
> *
>
>
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *John Bradley
> client_id definition issue (was: Client Instances)****
>
> ** **
>
> Phil,****
>
> ** **
>
> As I pointed out in the other thread,  redirect_uri is the thing that ties
> together the clients as that is the place the responses need to go to so is
> hard to fake.****
>
> ** **
>
> All instances of a particular client application will share the same
> redirect_uri across all instances.   ****
>
> ** **
>
> Adding a bunch of self asserted informational fields to the base spec is
> not really helping.  In a enterprise situation where all the apps play nice
> it might be helpfull but the reality is that you probably allready have a
> MDM that lets you manage app versions.****
>
> ** **
>
> John ****
>
> ** **
>
> On 2013-05-22, at 3:59 PM, Phil Hunt <[email-masked]> wrote:****
>
>
>
> ****
>
> I had a conversation with Justin yesterday to try to come to a resolution
> regarding my concerns about client instances and being able to associate
> client instances that are issued for the same client software. I think we
> made some progress.****
>
> ** **
>
> *Background:  *****
>
> client_id as refering to the client application software (e.g. the iPhone
> Facebook app). This is probably due to the types of OAuth2 implementations
> that existed at the time, where there was a single SP instance.  Others
> have interpreted that client_id does not refer to client applications but
> rather ideally should point to instances of software. To me this seems like
> equating a client_id to being a user-id -- IOW the key part of a credential
> rather than a client identifier. ****
>
> ** **
>
> However it does so without keeping track of client software that is the
> same.****
>
> ** **
>
> Never-the-less, I think both interpretations can be accommodated.****
>
> ** **
>
> Finally, in single instance services (like Facebook, Twitter, etc), there
> was a natural registration and approval cycle bound into the client_id
> issuance process. The developer was able to talk to the single service
> provider and obtain a client_id for all deployments. It wasn't stated, but
> the client_id registration sites served a useful way to do application
> approvals.  This is a difficult problem to solve when there are multiple
> instance of Resource API deployed in multiple locations. The developer
> can't contact them all.  Further, because the current draft loses knowledge
> of how to recognize that two instances of clients share the same software,
> essentially anonymous, and thus approval processes would not be possible.
>  Though it does not require it, this proposal makes it possible for service
> providers to recognize new software and to have approval process.****
>
> ** **
>
> *Proposal:*****
>
> What I have worked out with Justin (and he may not yet fully agree with
> everything) is a proposal that solves the problem in an optional way that
> will not break existing clients. ****
>
> ** **
>
> I also propose that optional version numbers also be supported. This is
> useful to service providers who need to know which client_ids are affected
> when certain software clients and/or versions are deprecated. The
> re-introduction of the renamed software_id further enables "local"
> registration to occur. The first time a client tries to register, a service
> provider could for example, choose to hold the registration to obtain
> administrative approval.****
>
> ** **
>
> The solution here is not intended to provide software "authentication" or
> software verification. The solution simply allows service providers to make
> pragmatic decisions about sets of clients that typically work the same way
> in a change managed environment. ****
>
> ** **
>
> parameters and the client provides them?  The current draft already covers
> this in Section 3.  Specifically:****
>
>  The Client Registration Endpoint MUST ignore all parameters it does not understand.****
>
>  ** **
>
> Below are 3 options for the group to consider.  My recommendation is for
> option 1. My concern is option 2 will lead to complexity because clients
> and service providers will attempt to encode versions and software
> identifiers into one field. I would rather keep this to simple UUIDs for
> most cases.****
>
> ** **
>
> *Option 1 (2 parameters):*****
>
> ** **
>
> software_id****
>
> This value MAY be required by registration endpoints. The value MAY be a
> unique identifier (UUID) self-assigned by a the client application
> developer, or it MAY be an assertion. The value SHOULD be the same across
> all instances of a client on an application platform. For example,
> software used in a mobile phone should be considered as different from a
> web server implementation though it may share the same code. The
> identifier *SHOULD NOT *change between software updates. While a client
> application MAY be issued multiple client_id's and client credentials over
> its deployment lifecycle, the software_id SHOULD NOT change.****
>
> ** **
>
> Signed assertions MAY be used as software identifiers to allow different
> dynamic registration end-points to recognize approval from a common issuer
> (for example in cases where the resource API released by a single publisher
> but deployed in many different domains). The decision to use assertions and
> the method by which developers know how to obtain assertions is out of
> scope for this specification.****
>
> ** **
>
> credential assertions for this purpose. I propose to standardize this in
> this field since an assertion would server the same purpose as a UUID only
> providing third party signing and other claims. I am concerned that passing
> a client assertion for this purpose creates complexity in client
> authentication processing - though obviously Justin has it working]****
>
> ** **
>
> software_version****
>
> RECOMMENDED. A version indicates a client developer chosen version number.
> The identifier SHOULD BE the same across all copies of client software. The
> version number SHOULD change between different client updates. The
> intention is that Service Providers MAY perform equality matching with
> software_id to sub-select groups of clients of a particular software
> version.****
>
> ** **
>
> *Option 2 (single parameter):*****
>
> ** **
>
> software_id****
>
> This value MAY be required by registration endpoints. The value MAY be a
> unique identifier (UUID) self-assigned by a the client application
> developer, or it MAY be an assertion. The value SHOULD be the same across
> all instances of a client on an application platform. For example, software
> used in a mobile phone should be considered as different from a web server
> implementation though it may share the same code. The identifier *SHOULD* change
> when the client software has changed such as with a version update or a
> platform change.****
>
>
>
> Signed assertions MAY be used as software identifiers to allow different
> dynamic registration end-points to recognize approval from a common issuer
> (for example in cases where the resource API released by a single publisher
> but deployed in many different domains). The decision to use assertions and
> the method by which developers know how to obtain assertions is out of
> scope for this specification.****
>
> ** **
>
> [note: same editorial note as option 1]****
>
> ** **
>
> *Option 3 (no change):*****
>
> ** **
>
> In this option, no changes to the draft are made. ****
>
> ** **
>
> another extension draft be written for these features as an extension to
> the dynamic registration draft. In my opinion, such a draft would be very
> small in size without clear reason for separation. My feeling is that some
> technical justification for keeping these features separated will likely be
> needed.****
>
> ** **
>
> Phil****
>
>
>
> @independentid****
>
> www.independentid.com****
>
> [email-masked]****
>
>
>
>
>
> ****
>
> ** **
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Justin Richer <[email-masked]>
Date: Wed, 22 May 2013 19:08:10 -0400

I think that's the crux of it: what, exactly, are the risks and the 
benefits of defining this as a single parameter now as opposed to part 
of a larger extension framework later?

 From my view, the risk to the protocol is fairly low (just another 
self-asserted client field). The risks to deployment are potentially 
high if servers start to use and trust the software_id as something they 
can trust to be anything meaningful on its own. I think we have to be 
very careful about avoiding that situation.

The benefits, from my view, are equally low, though. On its own, it's 
just a single hook, something else to add in to the table of heuristics 
of client behavior over the network, and only if you care about such 
things. But it at least gives you the *chance* of doing something right.

Extension protocols and enterprise servers are free to use it, extend 
it, further specify it as needed (indeed, as they are allowed to do 
without it being in the base spec -- but they might pick different names 
for it).

So long as the field is properly limited (like what I've suggested in 
Phil's other thread), I'm neither particularly for nor against including it.

  -- Justin

On 05/22/2013 06:58 PM, Nat Sakimura wrote:
> I can see developers start trusting the identifier and causing 
> problems later.
> 2013/5/23 Justin Richer <[email-masked] <mailto:[email-masked]>>
>
>     I agree with Prateek that redirect_uri isn't sufficient or
>     well-suited for this, but I also agree with John that software_id
>     on its own doesn't buy you a whole lot as a standalone field. It
>     could be a reasonable stepping stone to future, more
>     high-assurance work, but my question is then: is it really worth
>     it to define a field now when the real work will come later? Why
>     not just define the field then and make it fit better?
>
>      -- Justin
>
>
>>     I dont see a big issue with a faked software_id. As i said it was
>>     a minimal proposal with the door open to stronger assertions.
>>
>>     Rogue clients pretending to be something they are not is actually
>>     more evidence of a problem. In draft 10 you cant even do that.
>>
>>     Phil
>>
>>>     At the moment for Mobile devices and other native apps all we
>>>     have to reliably identify the app is the redirect_uri.
>>>
>>>     Yes in a well groomed enterprise trusting a self asserted
>>>     software identifier is nice but probably doesn't scale to the
>>>     real world.
>>>
>>>     I have had discussions with MDM venders about how you might be
>>>     able to tie access tokens to a instance of software on a device
>>>     and determine if that software is allowed to be run by that user
>>>     on that device.
>>>     These are all much more complicated discussions than just
>>>     sticking another registration parameter on.
>>>
>>>     I don't think this should block the basic dynamic registration
>>>     spec.   App lifecycle needs a full spec, and additional
>>>     registration parameters can be added later if required.
>>>
>>>     On 2013-05-22, at 6:00 PM, prateek mishra
>>>     <[email-masked] <mailto:[email-masked]>>
>>>     wrote:
>>>
>>>>     Well, I have to say that if anything seems poorly thought out,
>>>>     it would be a design with the following characteristics.
>>>>
>>>>     [quote]
>>>>     This seems to violate the most basic principles of software
>>>>     design - overloading a field with meaning distinct from its
>>>>     primary purpose!!
>>>>
>>>>     essential for identifying and disabling a class of clients that
>>>>     may have been found to have some security flaws, for example.
>>>>     This is a practical deployment issue that also impacts the
>>>>     security characteristics of OAuth.  It should be taken into
>>>>     account in the client registration process.
>>>>
>>>>     I hope we will take the time to discuss this issue carefully
>>>>     and not rush  to finalize a specification which has NOT
>>>>     received much review
>>>>>     extensions, and the proposed fields are optional, these could
>>>>>     be added later as a non-breaking change by another spec if the
>>>>>     working group eventually decides to pursue a route like the
>>>>>     one proposed below.  We don’t have to do it now for this to
>>>>>     eventually come into being after deliberate consideration of a
>>>>>     complete specification including these features by the working
>>>>>     group.
>>>>>
>>>>>     -- Mike
>>>>>
>>>>>     *From:[email-masked] <mailto:[email-masked]>
>>>>>     [mailto:[email-masked]] *On Behalf Of *John Bradley
>>>>>     *Cc:* [email-masked] <mailto:[email-masked]> WG
>>>>>     *Subject:* Re: [OAUTH-WG] Proposed resolution - Dynamic Reg -
>>>>>     Fix to client_id definition issue (was: Client Instances)
>>>>>
>>>>>     Phil,
>>>>>
>>>>>     As I pointed out in the other thread,  redirect_uri is the
>>>>>     thing that ties together the clients as that is the place the
>>>>>     responses need to go to so is hard to fake.
>>>>>
>>>>>     All instances of a particular client application will share
>>>>>     the same redirect_uri across all instances.
>>>>>
>>>>>     Adding a bunch of self asserted informational fields to the
>>>>>     base spec is not really helping.  In a enterprise situation
>>>>>     where all the apps play nice it might be helpfull but the
>>>>>     reality is that you probably allready have a MDM that lets you
>>>>>     manage app versions.
>>>>>
>>>>>     John
>>>>>
>>>>>     resolution regarding my concerns about client instances and
>>>>>     being able to associate client instances that are issued for
>>>>>     the same client software. I think we made some progress.
>>>>>
>>>>>     */Background: /*
>>>>>
>>>>>     software (e.g. the iPhone Facebook app). This is probably due
>>>>>     to the types of OAuth2 implementations that existed at the
>>>>>     time, where there was a single SP instance.  Others have
>>>>>     interpreted that client_id does not refer to client
>>>>>     applications but rather ideally should point to instances of
>>>>>     software. To me this seems like equating a client_id to being
>>>>>     a user-id -- IOW the key part of a credential rather than a
>>>>>     client identifier.
>>>>>
>>>>>     The new draft proposes that each instance be identified
>>>>>     separately. However it does so without keeping track of client
>>>>>     software that is the same.
>>>>>
>>>>>     Finally, in single instance services (like Facebook, Twitter,
>>>>>     etc), there was a natural registration and approval cycle
>>>>>     bound into the client_id issuance process. The developer was
>>>>>     able to talk to the single service provider and obtain a
>>>>>     client_id for all deployments. It wasn't stated, but the
>>>>>     client_id registration sites served a useful way to do
>>>>>     application approvals.  This is a difficult problem to solve
>>>>>     when there are multiple instance of Resource API deployed in
>>>>>     multiple locations. The developer can't contact them all.
>>>>>      Further, because the current draft loses knowledge of how to
>>>>>     recognize that two instances of clients share the same
>>>>>     software, there's no ability to have an approval process. Each
>>>>>     instance is essentially anonymous, and thus approval processes
>>>>>     would not be possible.  Though it does not require it, this
>>>>>     proposal makes it possible for service providers to recognize
>>>>>     What I have worked out with Justin (and he may not yet fully
>>>>>     agree with everything) is a proposal that solves the problem
>>>>>     in an optional way that will not break existing clients.
>>>>>
>>>>>     I also propose that optional version numbers also be
>>>>>     supported. This is useful to service providers who need to
>>>>>     know which client_ids are affected when certain software
>>>>>     clients and/or versions are deprecated. The re-introduction of
>>>>>     the renamed software_id further enables "local" registration
>>>>>     to occur. The first time a client tries to register, a service
>>>>>     provider could for example, choose to hold the registration to
>>>>>     allows service providers to make pragmatic decisions about
>>>>>     sets of clients that typically work the same way in a change
>>>>>     managed environment.
>>>>>
>>>>>     Question:  What happens if the server does not support these
>>>>>     new parameters and the client provides them?  The current
>>>>>     draft already covers this in Section 3.  Specifically:
>>>>>
>>>>>     Below are 3 options for the group to consider.  My
>>>>>     recommendation is for option 1. My concern is option 2 will
>>>>>     lead to complexity because clients and service providers will
>>>>>     attempt to encode versions and software identifiers into one
>>>>>     field. I would rather keep this to simple UUIDs for most cases.
>>>>>
>>>>>     This value MAY be required by registration endpoints. The
>>>>>     value MAY be a unique identifier (UUID) self-assigned by a the
>>>>>     client application developer, or it MAY be an assertion. The
>>>>>     value SHOULD be the same across all instances of a client on
>>>>>     an application platform. For example, software used in a
>>>>>     mobile phone should be considered as different from a web
>>>>>     server implementation though it may share the same code.The
>>>>>     identifier *SHOULD NOT *change between software updates. While
>>>>>     a client application MAY be issued multiple client_id's and
>>>>>     client credentials over its deployment lifecycle, the
>>>>>     different dynamic registration end-points to recognize
>>>>>     approval from a common issuer (for example in cases where the
>>>>>     resource API released by a single publisher but deployed in
>>>>>     many different domains). The decision to use assertions and
>>>>>     the method by which developers know how to obtain assertions
>>>>>     is out of scope for this specification.
>>>>>
>>>>>     standardize this in this field since an assertion would server
>>>>>     the same purpose as a UUID only providing third party signing
>>>>>     and other claims. I am concerned that passing a client
>>>>>     assertion for this purpose creates complexity in client
>>>>>     authentication processing - though obviously Justin has it
>>>>>     working]
>>>>>
>>>>>     software_version
>>>>>
>>>>>     RECOMMENDED. A version indicates a client developer chosen
>>>>>     version number. The identifier SHOULD BE the same across all
>>>>>     copies of client software. The version number SHOULD change
>>>>>     between different client updates. The intention is that
>>>>>     Service Providers MAY perform equality matching with
>>>>>     software_id to sub-select groups of clients of a particular
>>>>>     software version.
>>>>>
>>>>>     This value MAY be required by registration endpoints. The
>>>>>     value MAY be a unique identifier (UUID) self-assigned by a the
>>>>>     client application developer, or it MAY be an assertion. The
>>>>>     value SHOULD be the same across all instances of a client on
>>>>>     an application platform. For example, software used in a
>>>>>     mobile phone should be considered as different from a web
>>>>>     server implementation though it may share the same code. The
>>>>>     identifier *SHOULD* change when the client software has
>>>>>     different dynamic registration end-points to recognize
>>>>>     approval from a common issuer (for example in cases where the
>>>>>     resource API released by a single publisher but deployed in
>>>>>     many different domains). The decision to use assertions and
>>>>>     the method by which developers know how to obtain assertions
>>>>>     is out of scope for this specification.
>>>>>
>>>>>     Personal comment:  It has been proposed by several on the list
>>>>>     that another extension draft be written for these features as
>>>>>     an extension to the dynamic registration draft. In my opinion,
>>>>>     such a draft would be very small in size without clear reason
>>>>>     for separation. My feeling is that some technical
>>>>>     justification for keeping these features separated will likely
>>>>>     be needed.
>>>>>
>>>>>     Phil
>>>>>
>>>>>     @independentid
>>>>>