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
