A correction to my previous message below: a holder-of-key assertion can be sent in what seems to be a single message if the message is sent over a TLS connection and the assertion is about the key pair used in the connection. Of course that's not really a single message, because there are multiple messages involved in the TLS handshake, and it's precisely the TLS handshake that shows that the subject it is the holder of the private key.
Specifically, an assertion sent in the body of an HTTP POST request over a TLS connection can be used to bind a certificate used as TLS client certificate to additional data about the subject of the certificate. And an assertion sent in the body of a response to an HTTP request over a TLS connection can be used to bind the certificate used as TLS server certificate to additional data about the subject of the certificate. Francisco --- On Sat, 1/22/11, Francisco Corella <[email protected]> wrote: From: Francisco Corella <[email protected]> Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme To: [email protected] Cc: "Karen P. Lewison" <[email protected]> Date: Saturday, January 22, 2011, 6:28 AM Brian, > I guess it's somewhat moot now because client assertions > have been removed from the latest draft. However, I don't > believe there anything saying that client assertions had to > be bearer assertions. Nor would that really have been > appropriate for the framework spec. Ah, so I was right in thinking there was something wrong :-) You can only use a bearer assertion (or "could" since assertions are no longer in the spec). If a subject (here, the client) authenticates itself by sending a single message that contains an assertion, the assertion cannot be a holder-of-key assertion. A holder-of-key assertion is an assertion about the holder of a private key whose corresponding public key or certificate is contained in the assertion. The subject must confirm that it has the private key. The subject typically does that by signing a nonce supplied by the relying party (here, the authorization server). That party must send the nonce in an earlier protocol message. Actually, an assertion that authenticates the subject by the mere fact of being presented by the subject is, by definition, a bearer assertion. That's what "bearer" means. It means "this assertion is about whoever bears it (carries it, produces it); the bearer does not have to present any other proof if its identity". > The same is true for extension/URI grant types (formerly > known as assertion grant types). There is nothing in the > core OAuth framework spec saying that it is, or has to be, a > bearer assertion. The SAML Bearer Assertion Grant Type > Profile is an extension spec that constrains/defines the > specific use of bearer SAML assertion. To me and some > others, that seemed like a useful enough use-case to write > an I-D for, however, the main OAuth spec allows for other > extensions. A holder of key SAML Assertion, for example, > might be profiled as a grant type. Or something completely > non SAML based. The same would be true for obtaining an access token by presenting a SAML assertion as an access grant. It would have to be a bearer assertion, not a holder-of-key assertion. As for a non-SAML token, it would have to be a bearer token, by definition of the word "bearer". But it's not just a matter of definition. There is a security requirement for any token to be usable as a bearer token: it must only become known to the subject and the verifier. So it must be sent by the asserting party to the subject, and then from the subject to the relying party, through channels that provide confidentiality and authentication of the destination (such as ordinary TLS connections). And all three parties must keep the bearer token secret. By the way, I saw in the discussion that some existing implementations are using assertions. Hopefully they are using bearer assertions. Francisco -----Inline Attachment Follows----- _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
