Change "holder of key" to "sender constrained"

[Dave Tonge]

I think we should make an editorial change to use the phrase “sender constrained” as this is used in the security-topics document and oauth-mtls.

[Brian Campbell]

For whatever pedanticness it’s worth, the phrase “sender constrained” doesn’t appear at all in oauth-mtls/RFC8705. There was pushback on the terminology during (one) WGLC - search for the word “constrained” in https://mailarchive.ietf.org/arch/msg/oauth/k7sFYL7jAFnI0d_NFlvemWTc88A/ which was in response to https://mailarchive.ietf.org/arch/msg/oauth/NrpieecT1nUKiTbHKCk1TU2VjFs/

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.

[Dave Tonge]

Thanks Brian - I must have remembered it from an earlier version.

RFC8705 refers to Certificate-Bound Access Tokens

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15 refers to sender-constrained

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?

[Tom Jones]

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

[Brian Campbell]

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?

[Tom Jones]

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.

[Dave Tonge]

We agreed that @Torsten Lodderstedt would review the text to check for consistency with OAuth security topics

[Dave Tonge]

PR merged