I agree that any new field or fields should be defined once the requirements
and flows are well-specified and well-understood as part of a complete
specification for those flows and use cases.
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Wednesday, May 22, 2013 3:47 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)
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<mailto: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<mailto: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>
[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<mailto: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<mailto: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<http://www.independentid.com/>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
