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

[Richer, Justin P.]

On Nov 7, 2013, at 12:41 AM, Vladimir Dzhuvinov / NimbusDS <vladimir at nimbusds.com>
 wrote:

> 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.

> 
>> 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?

We can probably clean up the language around the relationship here, but Vladimir's got the right idea.

> 
> Vladimir
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab