I guess I'm not saying that this editorial change is the wrong thing to do. But realize there’s some varied use of language already that’s not going to be reconciled just by choosing a particular one here.
Thanks Brian - I must have remembered it from an earlier version.
I just don’t think we should introduce another term.
@Torsten Lodderstedt and @Daniel Fett are you aware of the pushback on “sender-constrained” that was received for RFC8705?
i agree with brian - this is not a common term of art - i personally believe we need to focus on binding as the appropriate term of art
I don’t think there is a generally agreed upon or widely understood term of art, which is part of the problem. I’ve tried to capture that in the excerpt below from my upcoming Identiverse® presentation, “The Burden of Proof”. “sender constrained” is maybe/probably as good as any of them. But I was compelled to point out that RFC8705 doesn’t use the term at all. Perhaps going with “sender constrained” but also providing a brief definition would be advisable?
one big problem with “sender constrained” is that is sounds like the sender is constrained, which is not, in fact, true. It is not even clear who the sender is with channel binding. Before we can move to a defensible position we need to eliminate channel binding. I think the community has conflated two or more issues. First of all is proof-of-presence, which you left out, and proof of control of the credential, all a signature shows is proof of access to the credential. Good luck with your disambiguation process. A good taxonomy is very valuable and should be created. No committee seems to own an identity taxonomy. In fact no committee agrees on the meaning of identity.