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

[prateek mishra <[e-mail]>]

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



> +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:*[e-mail] [mailto:[e-mail]] *On 
> Behalf Of *John Bradley
> *Sent:* Wednesday, May 22, 2013 2:21 PM
> *To:* Phil Hunt
> *Cc:* [e-mail] 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
>
> On 2013-05-22, at 3:59 PM, Phil Hunt <[e-mail] 
> <mailto:[e-mail]>> 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: /*
>
> 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 <http://www.independentid.com/>
>
> [e-mail] <mailto:[e-mail]>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth