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