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 phil.h...@oracle.com
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
