[OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10

[Phil Hunt <[e-mail]>]

It seems unfortunate that I have not gotten a chance to get into this level of detail much earlier. But then, I guess that's what LC review is for! My apologies for not getting many of these concerns to the WG much earlier.

Overall  
-----------
I think dynamic registration is a critical part of the OAuth framework now that we are starting to consider how individual client applications should operate when there is one or more deployments of a particular resource API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to standards based, open source based, and commercial based deployments where there are multiple service endpoints and many clients to manage.

The dynamic registration spec is actually dealing with a couple of issues that I would like to see made more clear in early part of the spec:

1.  How is a new client application recognized for the first time when deployed against a particular SP endpoint?  Should clients actually assert an application_id UUID that never changes and possibly a version id that does change with versions?

2.  How are client credentials managed. Are we assuming client credentials have a limited lifetime or rotation policy?  How does a client authenticate the first time and subsequent times to the registration service?

3.  How is versioning of clients managed? Should each new version of a client require a change in client registration including possibly changing client_id and authentication credential? I don't have a strong feeling, but it is something that implementors should consider.

4.  What is the registration access token? Why is is used? What is its life-cycle?  When is it issued, when is it changed? When is it deleted?

If we distinguish between first time registration of a particular client software package, it is possible that somethings like authentication method can be negotiate in or out-of-band at that time. Subsequent registrations should only have parameters for items that could change per deployment (like tos_uri).  I think token_endpoint_auth_method is one thing that should not be negotiated per instance.

When subsequent instances register, I have to ask the question, for example when would things like "token_endpoint_auth_method" be negotiated or be different for the same client software? Should not all instances use the same authentication method.

Finally, there seems to be an inconsistent style approach with draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do so as well?

Specific items:
---------------------
"token_endpoint_auth_method"

There is some confusion as to whether this applies to server or client authentication.  Suggest renaming parameter to "token_endpoint_client_auth_method"

* Currently, the API only supports a single value instead of an array.  If the purpose is to allow the client to know what auth methods it supports, this should be an array indicated what methods the client supports - or it should not be used.

* There is no authn method for "client_secret_saml" or "private_key_saml".

There are no profiles referenced or defined for "client_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover these types of flows. They only cover bearer flows.  "client_secret_jwt" and "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does not fully define these either.

There is no authentication method defined for "client_bearer_saml" or "client_bearer_jwt" or "client_bearer_ref".  Since the bearer specs say this is acceptable,  the dynamic registration spec should accept these.

A possible suggestion is to remove client_secret_jwt and private_key_jwt and define those as register extensions since these profiles are not defined.


About "tos_uri" and "policy_uri"

The distinction between tos_uri and policy_uri is unclear.  Can we clarify or combine them?

Also, aren't these really URIs or are they meant to be URLs?

About "jwks_uri"

A normative reference for http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed. 
 
Should be URL instead of URI?

Section 2.1

In the table urn:ietf:params:oauth:grant-type:jwt-bearer is missing.

“As such, a server supporting these fields SHOULD take steps to ensure that a client cannot register itself into an inconsistent state.”

We may want to define more detailed HTTP error response. E.g. 400 status code + defined error code (“invalid_client_metadata”)?

Section 2.2

May want to add:

When “#” language tag is missing, (e.g. “#en” is missing in “client_name”, instead of “client_name#en”) the OAuth server may use interpret the language used based on server configuration or heuristics.

Section 3

Existing text:

“In order to support open registration and facilitate wider interoperability, the Client Registration Endpoint SHOULD allow initial registration requests with no authentication.  These requests MAY be rate-limited or otherwise limited to prevent a denial-of-service attack on the Client Registration Endpoint.”

I would suggest to change the first “SHOULD” to “MAY”.   In most cloud services, the first client is registered by a human user. Then, other clients can be further used to automate other client registration.  So, the first request would typically come with an authenticated user identity. 

On the flip side, the earlier paragraph:

“The Client Registration Endpoint MAY accept an initial authorization credential in the form of an OAuth 2.0 [RFC6749] access token in order to limit registration to only previously authorized parties. The method by which this access token is obtained by the registrant is generally out-of-band and is out of scope of this specification.”

I tend to think it would be better to change this “MAY” to “SHOULD”.

That access token would carry a human user authenticated identity somehow. In some cases, it can be a pure authenticated user assertion token.

About section 4.3:

If the client does not exist on this server, the server MUST respond
   with HTTP 401 Unauthorized, and the Registration Access Token used to
   make this request SHOULD be immediately revoked.

If the Client does not exist on this server, shouldn't it return a "404 Not Found"?

If revoking the registration access token, is it bound to a single client registration?  This is not clear.  What is the lifecycle around registration access token? Only hint is in the Client Information Response in section 5.1.
 
About section 5.1:

Is registration_access_token unique?  Or is it shared by multiple instances?   If shared, then registration_access_token can't be revoked on delete of client.

Suggest rename “expires_at” to “client_secret_expires_at”, 

Suggest to rename “issued_at” to “id_issued_at”

Section 7

When a client_secret expires is it the intent that clients do an update or refresh to get a new client secret?

Phil

@independentid
www.independentid.com
[e-mail]