Am 11.01.2011 06:44, schrieb Manger, James H:
- Authentication schemes
You propose to use the authentication scheme name "OAuth2" for the
WWW-Authenticate header but another scheme name "MAC" for the
authorization header. I've never seen such an asymmetric approach before.
Don't you think people get confused about that?
This was proposed by James Manger and discussed earlier on the list. I'll let
James explain it.
The MAC draft doesn't bother to define a "WWW-Authenticate: MAC ..." response
header because Eran is only interested in using MAC in conjunction with OAuth2.
The server can say (in response to an unauthenticated request): "you can use OAuth flows to be
delegated access to this server". It says this with a "WWW-Authenticate: OAuth2"
response. This statement is not specific to MAC.
I think the MAC scheme should define its own "WWW-Authenticate: MAC ..."
response header. It might not be used by systems using OAuth2, but it makes MAC a more
complete standalone HTTP authentication mechanism.
Moreover, the bearer draft
also uses the name "OAuth2" in the authorization header. Why this
difference? Why don't you just add some parameters to the "OAuth2"
scheme?
The bearer draft should change to use its own scheme name (eg "BEARER") in
Authorization request headers.
I'm trying to understand your proposal.
Let's assume a client sends a unauthorized request to a protected
resource. The resource server answers with 401/WWW-Authenticate OAuth2.
What is the client supposed to learn from this response? It can use an
OAuth2-Server to obtain a token, correct?
The client additionally needs an indication which authorization header
(== mechanism) to use for the service invocation. An additional header
WWW-Authenticate "MAC" could indicate support for MAC authorization
headers whereas WWW-Authenticate "BEARER" could indicate support for
BEARER authorization headers.
Bottom line: The server has at least to send "MAC" or "BEARER" and can
additionally send "OAuth2".
As far as I understand, WWW-Authenticate headers are intended to signal
the authentication methods a certain server supports + to deliver method
specific parameters to the caller. Nothing more. I feel your
interpretation goes beyond that point in that this headers shall tell
the client not only (1) how to send credentials accross but als (2) how
to obtain this credentials.
I would suggest to publish (2) by other means than a WWW-Authenticate
header.
regards,
Torsten.
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
