My understanding is you can still do it. It is covered by the new other auth mechanism paragraph.
The real question is do we need it for interop purposes or not? We had other methods that didn't fit draft 11 either. So do u spec them all or just one mandatory to implement? Phil Sent from my phone. On 2011-01-21, at 22:28, Francisco Corella <[email protected]> wrote: > 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
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
