Comments on the OAuth Dynamic Client Registration Protocol [draft-oauth-dyn-reg-v1-02]:
I found it hard to gleam from this draft where any trust in the client information being registered comes from. Sources could be: self-asserted; PKI with well-known roots; or DNS. OpenID and WebID are two existing approaches for authenticating to a server you have never met before. A client logging in to an authorization server (AS) using one of these techniques then accessing a specific page could be treated as a registration. [A variant of OpenID suitable for apps, as opposed to users, is sorely needed.] Section 6: "Client Registration with Pushed Metadata" The draft talks about an authorization server "verifying information received from the client" [6.2] but with no clues as to what is verified or how. Checks that client_name doesn't contain control characters, client_uri is syntactically correct, or that client_uri returns "200 OK" and text/html content are possible, but almost meaningless. They don't tell the AS that the values are appropriate for the client that it is talking to. Section 7: " Client Registration with Pushed URL and Pulled Metadata" Pushing a URL appears insecure. A malicious app POSTs another apps client_url (7.1) and gets a client_id and client_secret for that app in return. Perhaps signing the POSTed client_url helps (the draft says a client MAY do this), but it isn't obvious to me how the AS checks the signer is the right entity. Must the same certificate (or same key, or same cert subject...) be used to sign the POST and to serve the metadata the AS subsequently gets from https://.../.well-known/host-meta? Section 6.2: "Client Registration Response" [and 6.3 and 7.3 and 7.4] This looks like another version of an OAuth2 token response [draft-ietf-oauth-v2-15#section-5.1]. It conveys similar data (dynamically-issued credentials), but makes up another format. It doesn't tell the client how or where to use the credentials (ie which authentication mechanisms, and which servers). This draft and OAuth2 would be helped if we defined an explicit media type for credentials: eg application/credentials+json. This draft could use it to return client credentials. OAuth2 could use it to return credentials representing a user's delegation to a client etc. It could cover the common needs: id, auth mechanism, where it is safe to use, lifetime, renewal, multiple credentials, errors.... -- James Manger _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
