There are two main things that I dislike about this proposal, but
neither are insurmountable in my view.
1) Version. I think that the entire notion of "version" is as slippery a
slope as "software identifier" is in the first place. And as soon as you
start talking about "version" people are going to want to do linear
comparisons, to say things like "version > 3.1.0" and not just "version
== 3.1.0, 3.1.1, 3.1.2, ...". I would suggest dropping version all together.
2) Assertions. I think that if you're going to do assertions, do them as
part of the the initial registration request's authorization (via an
OAuth token). That's exactly the kind of thing that the oauth-token
functionality was put there for, and we don't need to conflate this with
the software identifier. I would suggest not mentioning assertions at
all. If you want to tie down things like software_id (or redirect_uri,
or anything else), you'll need to specify other things in order to do it
in an interoperable way, like how to format or parse the assertion or
how to call a discovery service to correlate things.
So if this were to go in, I would rather see it like this (Option 4):
software_id
The value an identifier for the client software being registered. It is
RECOMMENDED that clients send this value to help Authorization Servers
facilitate client management. The content and structure of this value
are out of scope for this specification, and as all Client Metadata is
assumed to be self-asserted the Authorization Server MUST NOT make any
security decisions based on the value of this field alone. This field
MAY be a random value (such as a UUID) self-assigned by the client
application developer or it may be supplied by another party. 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.While a client application MAY be issued multiple
client_id's and client credentials over its deployment lifecycle, the
software_id SHOULD NOT change.
While I don't think it gives you *real* hooks without specifying ways to
verify and validate the value in this field, and I don't think such
mechanisms belong in this spec, I don't think that adding this field
hurts much.
On the same token, I'm not convinced it's worth it, but if Phil,
Prateek, and others thing that this would provide enough of a hook for
what they want to do without breaking existing extensions and profiles
of Dyn Reg (clients don't have to send it, servers can ignore it) that
we could actually unstick this issue and move things forward.
I think that the *real* work is still ahead of us with regard to
instance management, as I think there's a lot more to this particular
nut to be cracked that can be solved better in its own specification.
-- Justin
On 05/22/2013 03:59 PM, Phil Hunt 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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
