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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
