Hi all,
I asked for feedback regarding the removal of the client assertion credentials
earlier this month, see
http://www.ietf.org/mail-archive/web/oauth/current/msg05261.html
Unfortunately, the feedback did not lead to any new insight other than there
are three groups of people:
1) Those who want the functionality removed from the draft
2) Those who want it to be included.
3) Those who want something different in the document (namely a stronger
version).
These three groups are equally large (based on the feedback).
I have attached the text from version -11 of the draft.
So, my suggestion to the group therefore is for those who are interested in
this functionality in one way or the other to provide text that the group can
agree with in time before we submit the document to the IESG (1).
If that does not happen the client assertion credential will have to be
developed as a separate document (if there is enough energy and interest in the
group).
A note regarding (1): Currently, the security consideration section is missing
since otherwise the document is ready for a working group last call (in my
view).
So, once that is there and agreed I will start a working group last call.
Ciao
Hannes
-----
3.2. Client Assertion Credentials
The client assertion credentials are used in cases where a password
(clear-text shared symmetric secret) is unsuitable or does not
provide sufficient security for client authentication. In such cases
it is common to use other mechanisms such as HMAC or digital
signatures that do not require sending clear-text secrets. The
client assertion credentials provide an extensible mechanism to use
an assertion format supported by the authorization server for
authentication the client.
Using assertions requires the client to obtain an assertion (such as
a SAML [OASIS.saml-core-2.0-os] assertion) from an assertion issuer
or to self-issue an assertion. The assertion format, the process by
which the assertion is obtained, and the method of validating the
assertion are defined by the assertion issuer and the authorization
server, and are beyond the scope of this specification.
When using a client assertion, the client includes the following
parameters:
client_assertion_type REQUIRED. The format of the assertion as
defined by the authorization server. The value MUST be an
absolute URI.
client_assertion REQUIRED. The client assertion.
For example, the client sends the following access token request
using a SAML 2.0 assertion to authenticate itself (line breaks are
for display purposes only):
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=i1WsRn1uB1&
client_assertion=PHNhbWxwOl[...omitted for brevity...]ZT4%3D&
client_assertion_type=
urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
When obtaining an access token using a client assertion together with
an authorization code (as described in Section 5.1.1), a mechanism is
needed to map between the value of "client_id" parameter used to
obtain the authorization code, and the client assertion. Such
mechanism is beyond the out of scope for this specification, but MUST
be specified for any client assertion type used in combination with
an authorization code.
The authorization server MUST reject access token requests using
client assertion credentials that do not contain HMAC or signed
values that:
o State the assertion was specifically issued to be consumed by the
receiving endpoint (typically via an audience or recipient value
containing the receiving endpoint's identifier).
o Identify the entity that issued the assertion (typically via an
issuer value).
o Identify when the assertion expires as an absolute time (typically
via an expiration value containing a UTC date/time value). The
authorization server MUST reject expired assertions.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
