[Openid-specs-ab] Review Comments on Dyn Reg
Richer, Justin P.
jricher at mitre.org
Thu Nov 7 15:47:35 UTC 2013
On Nov 7, 2013, at 12:41 AM, Vladimir Dzhuvinov / NimbusDS <vladimir at nimbusds.com>
> 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.
Exactly - we wanted to tie the values together in such a way that it would be clear what's being used when you take them together.
>> 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
If you're handing out client secrets that aren't uniquely tied to client_ids, then you're going to end up with problems as some of your dynamically registered clients are going to be able to more easily impersonate each other. Normally this is a sufficiently random blob, but it can be a signed blob or something else of that nature, too. You can of course use credentials other than a client secret.
>> "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
> 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?
We can probably clean up the language around the relationship here, but Vladimir's got the right idea.
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab