By #3 Hannes meant defining another option in the spec, not just allowing it to be defined elsewhere.
EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Phillip Hunt > Sent: Friday, February 18, 2011 10:22 AM > To: Hannes Tschofenig > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Client Assertion Credentials (again) > > You can put in client_assertion but also leave the 'other' credential option > there as well > > Phil > > Sent from my phone. > > On 2011-02-18, at 10:17, Hannes Tschofenig <hannes.tschofe...@gmx.net> > wrote: > > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
