Re: [OAUTH-WG] OAuth 2.1-03 - WG adoption?

[Vladimir Dzhuvinov <[e-mail]>]

I find 03 well structured, well written and it shows that a lot of
thought and work has gone into it.

If this is a formal call for adoption - I support it.


> - defined new client type - credentialed clients - a client that has
> credentials, but the AS has not confirmed the identity of the client.
> Confidential clients have had their identity confirmed by the AS. We
> talked about changing the names of confidential and public, but
> thought that would be confusing. This new definition cleans up the
> text substantially.

I understand why this new client type was introduced. For the reader who
is not familiar with the recent OAuth RFCs and drafts - I suspect this
can still be confusing. There will likely be questions -- Why does this
difference between confidential and credentialed matter? What is a
concrete example of a credentialed client?

Also, people will likely ask themselves - what does the confirmation of
a (credentialed) client's identity by the AS actually mean and do?
(section 2.1)


>    Authorization servers SHOULD consider the level of confidence in a
>    client's identity when deciding whether they allow such a client
>    access to more critical functions, such as the Client Credentials
>    grant type.

Again, normative text that relies on the implementer being able to
assign levels of confidence in the client's identity, but is not
immediately obvious how to go about this.


There is mention in 9.1 about "enlisting the resource owner to confirm
identity" and "if there is a web application whose developer's identity
was verified...". But this talk about client identity is secondary and
happens in the context of client authentication.

Perhaps it will make sense to promote the discussion about identity to a
new 9.x section "Client identity" or "Client Identification", before
"Client Authentication". Addressing the topics what client identity is,
why does it matter (especially for security), and the "confirmation by
the AS". Then proceed with "Client Authentication" which now is freed to
focus on the credentials / auth methods aspects.

>    Such credentials are either issued by the
>    authorization server or registered by the developer of the client
>    with the authorization server.

Credentials (public key) can also be registered by a client performing
dynamic registration (section 2.1)


Vladimir