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 <jric...@mitre.org> > 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 <ve7...@ve7jtb.com> wrote: > > 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 <prateek.mis...@oracle.com> > 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 > 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:* oauth-boun...@ietf.org > [mailto:oauth-boun...@ietf.org<oauth-boun...@ietf.org>] > *On Behalf Of *John Bradley > *Sent:* Wednesday, May 22, 2013 2:21 PM > *To:* Phil Hunt > *Cc:* oauth@ietf.org 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 <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**** > > ** ** > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
