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] *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
<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
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
