> > >> Assertions used in the protocol exchanges defined by this >> specification MUST always be protected against tampering using a >> digital signature or a keyed message digest applied by the issuer. >> >> Why is that? Aren't you using assertions over a protected channel (as >> required by the spec) and therefore not need to sign the assertions? >> Indeed, why would a self-issued Bearer Assertion need to be signed at >> all? Does that even make sense? >> >> > Yes, assertions are sent over a protected channel, which does provide > integrity protection for the transport form client to AS and also gives > server authentication. But it doesn't provide client authentication, which > is kind of the point of the Client Authentication part of this draft. And > for authorization the signing or MACing is what authenticates the issuer of > the assertion - sometimes the issuer is the client but often the issuer > will be a 3rd party system. > > I do agree with you in one specific case that, if the client is trusted to > be the assertion issuer and the client is properly authenticated, then an > unsigned assertion could be reasonably used as an authorization grant. But > it's a fairly rare and very specific case. And one that can be accommodated > in other ways. So it's not worth introducing the complexity and potential > security problems that having the signature be option would bring. >
In other words, the assertion must be protected against tampering *by the party that presents the assertion*. That is a significant point, and you should say it. Barry
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
