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 <phil.h...@oracle.com> 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 > phil.h...@oracle.com > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
