[Openid-specs-ab] Review Comments on Dyn Reg

Vladimir Dzhuvinov / NimbusDS vladimir at nimbusds.com
Thu Nov 7 08:41:59 UTC 2013

Hi Torsten,

> grant_types - there is no grant type "implicit". I therefore suggest to 
> remove this bullet and all occurrences of "implicit" in the following 
> table of response type/grant type combinations.

While it's true that the "implicit" grant does not denote an actual
thing that is exchanged for an access token, I do think there's
usefulness in having that term and it can also be argued that the OAuth
2.0 RFC instates it.

> I would an "implicit" client expect just to register the response types 
> token or id_token (and the respective combinations).

OIDC reg is intended to be an extension of the common OAuth 2.0
draft-ietf-oauth-dyn-reg-14 which uses the "response_types" +
"grant_types" combo to allow for registrations where for instance only
JWT assertion are used:

"response_types" : [],
"grant_type" : ["urn:ietf:params:oauth:grant-type:jwt-bearer"]

Here it becomes apparent that if we remove the "implicit" keyword we
will not be able to differentiate between clients that use only the
implicit grant and clients that use only assertions at the token
endpoint. Hence it's good to have "implicit" even if it doesn't denote
and actual object/assertion.

> client_secret - "This MUST be unique for each client_id." - why must the 
> client secret be _unique_? This seems to be a rather hard requirement.

+1 on that

> 5.
> "to be able to view and update its registered information" - I only see 
> a specification of the read operation. Where is the update? As the next 
> states "The only method defined for use at this endpoint by this 
> specification is the HTTP GET method" I think the update should be 
> removed.

I think that is another artefact from draft-ietf-oauth-dyn-reg's
relation which the OIDC spec does not mention, but it's a fact. What is
the wise thing to do about that?


More information about the Openid-specs-ab mailing list