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

[Nat Sakimura <[e-mail]>]

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 <[e-mail]>

>  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 <[e-mail]> 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 <[e-mail]>
> 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:* [e-mail] [mailto:[e-mail]<[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]> 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****
>
> [e-mail]****
>
>
>
>
>
> ****
>
> ** **
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en