I support this approach. EHL
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Friday, February 18, 2011 10:17 AM > To: OAuth WG > Subject: [OAUTH-WG] Client Assertion Credentials (again) > > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
