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
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
