Fair point. I'll add some text saying that in the next revision. On Wed, Oct 15, 2014 at 5:18 PM, Barry Leiba <barryle...@computer.org> wrote:
> >>> 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
