15:20:23 <RRSAgent> RRSAgent has joined #vcwg-special
15:20:27 <RRSAgent> logging to https://www.w3.org/2023/05/02-vcwg-special-irc
15:20:27 <TallTed> RRSAget isn't here -- logging for minutes isn't happening
15:20:44 <TallTed> Zakim, who's here?
15:20:44 <Zakim> Present: DavidC, ivan, shigeya, mprorock, kristina, identitywoman, selfissued, olvier, brent, dlongley, markus_sabadello, andres, Phil-ASU, jandrieu, oliver, abramson, JoeAndrieu_,
15:20:44 <kristina_> q+ selfissued
15:20:45 <TallTed> q?
15:20:48 <Zakim> ... pdl_ASU, dmitriz, kristina_, TallTed
15:20:48 <Zakim> On IRC I see RRSAgent, TallTed, pdl_ASU, JoeAndrieu_, kristina_, will, oliver, markus_sabadello, andres, brent, DavidC, hsano, mprorock, Zakim, ivan, manu, csarven, cel, dlehn,
15:20:50 <Zakim> ... dlongley, stenr, shigeya
15:20:59 <selfissued_> selfissued_ has joined #vcwg-special
15:21:08 <JoeAndrieu_> kristina: is there a middle ground between the two names? confidence v confirmation
15:21:11 <pdl_ASU> pdl_ASU q-
15:21:11 <selfissued_> present+
15:21:13 <kristina_> ack oliver
15:21:16 <JoeAndrieu_> ... let's timebox this for 10-15 minutes
15:21:21 <selfissued_> q+
15:21:31 <kristina_> q- selfissued
15:21:54 <JoeAndrieu_> oliver: Wondering why confirmation cannot be used. Why is confidence is the better term? Thanks to Dave, I can see the difference.
15:22:14 <JoeAndrieu_> ... I agree. What if we prefix it as subjectConfirmationMethod?
15:22:15 <dlongley> q+ to speak to holder prefix problems
15:22:36 <JoeAndrieu_> ... The other point Dave made. I agree.
15:23:30 <JoeAndrieu_> ... maybe renaming with subject as prefix?
15:23:46 <DavidC> -1 to subjectConfirmationMethod since this no longer makes it generic for issuee or prover
15:23:51 <JoeAndrieu_> selfissued_: part of why I'm here is to try to have VCs fit into the rest of the identity ecosystem well.
15:23:59 <kristina_> proposed compromise: HolderConfirmationMethod or SubjectConfirmationMethod
15:24:07 <JoeAndrieu_> ... in this case, there is already an established term for this, e.g., the JWT confirmation claim
15:24:26 <JoeAndrieu_> ... it can be used for keys but also other types of confirmation
15:24:30 <kristina_> DavidC, I think the scope of this confirmation work was only for holder/subject?
15:24:38 <JoeAndrieu_> ... SAML also had a confirmation method, it could be a key, an IP address, or other things
15:24:57 <JoeAndrieu_> ... So you could put biometrics in there. You could use whatever kind of confirmation you want.
15:25:07 <mprorock> +1
15:25:08 <JoeAndrieu_> ... I think we run afoul of the greater industry if we use a different term
15:25:14 <JoeAndrieu_> ... that's a disfunction we should avoid.
15:25:27 <JoeAndrieu_> ... I support Dave Longley's point that you can't confirm the truth of claims
15:25:33 <JoeAndrieu_> ... Noone is saying that.
15:25:46 <JoeAndrieu_> ... The recipient always has to make a trust decision based on whatever information they have available.
15:25:53 <JoeAndrieu_> ... not prefixing it or changing it to something else
15:25:54 <kristina_> q?
15:26:03 <kristina_> ack selfissued_
15:26:05 <kristina_> ack dlongley
15:26:05 <Zakim> dlongley, you wanted to speak to holder prefix problems
15:26:39 <JoeAndrieu_> dlongley: speaking to Oliver's question about prefixing. I think adding those prefixes probably limits the general utility and might lead to a proliferation of terms that link to the same types of things
15:27:00 <JoeAndrieu_> ... Regarding reuse of confirmation method because its an industry term:
15:27:15 <DavidC> kristina, Oliver started this discussion by saying the other issues were orthogonal because the confirmationMethod could be used by issuee and provier (if they are added)
15:27:19 <JoeAndrieu_> ... current industry usage: my understanding was that those approaches were a subset of what we are trying to cover.
15:27:28 <selfissued_> q+
15:27:41 <JoeAndrieu_> ... I don't know that the confirmation method was intended to be, but reading the RFCs, I don't see that
15:27:56 <JoeAndrieu_> ... There is also other use in the industry that are at odds
15:28:18 <JoeAndrieu_> ... Sometimes it is harmful for us to take terminology for other use cases (two party models) and apply that to three party models
15:28:23 <oliver> q+
15:28:24 <JoeAndrieu_> ... that leads to confusion and problems.
15:28:33 <TallTed> +1 misalignment between 2-party and 3-party model-focused terms
15:28:56 <JoeAndrieu_> ... One way to resolve that is to have confidenceMethods, within which we can have confirmationMethods that map to industry terms
15:29:45 <JoeAndrieu_> kristina: looks like there's nothing normative in the PR tying this property to confirmation in the IETF RFC 7800
15:30:01 <JoeAndrieu_> q+
15:30:07 <TallTed> link isn't available to me since RRSAgent was later than me... please repost link?
15:30:08 <kristina_> selfissued_
15:30:23 <JoeAndrieu_> selfissued_: to Dave's point about whether confirmationMethod is broad enough
15:30:35 <kristina_> s/selfissued_/ack selfissued_
15:30:35 <JoeAndrieu_> ... as I pointed out both the SAML and JWT properties are extensible by design
15:30:38 <kristina_> q?
15:30:48 <ivan> ack selfissued_
15:30:48 <kristina_> ack selfissued_
15:30:49 <dlongley> "The "cnf" claim value MUST represent only a single proof-of-possession key; thus, at most one of the "jwk", "jwe", and "jku" (JWK Set URL) confirmation values defined below may be present.  Note that if an application needs to represent multiple proof-of-possession keys in the same JWT, one way for it to achieve this is to use other   claim names, in addition to "cnf", to hold the additional proof-of-possession key information." <-- the
15:30:49 <dlongley> RFC recommends using other names: https://www.rfc-editor.org/rfc/rfc7800.html
15:30:53 <JoeAndrieu_> ... I already cited the example that in SAML you can use an IP address for confirmation
15:31:01 <JoeAndrieu_> ... That's kind of on par with using a biometric
15:31:14 <kristina_> ack oliver
15:31:18 <JoeAndrieu_> ... So we would be harming ourselves if we invent a different term with the same meaning
15:31:45 <JoeAndrieu_> oliver: on dlongley's point, in JOSE you can interpret in a three party model
15:32:07 <JoeAndrieu_> ... it's not always about an oauth server that issues an access token then a client that accesses a resource service
15:32:25 <JoeAndrieu_> ... the cnf claims spec also says that the cnf claim carries confirmation method
15:32:35 <JoeAndrieu_> ... There exist other confirmation methods
15:32:44 <dlongley> scribe+
15:32:47 <kristina_> ack JoeAndrieu_
15:33:27 <dlongley> JoeAndrieu_: I came into this favoring `confirmationMethod` but I find Dave's argument fairly compelling. One of the reasons we came into the this work is around flawed mental models in the ID industry. Those flaws result in things that don't solve the problems right.
15:33:47 <kristina_> q?
15:33:50 <dlongley> JoeAndrieu_: I think this distinction between increasing confidence vs. confirmation truth is important and confidence maps more closely to what people are trying to do.
15:33:59 <dmitriz> dmitriz has joined #vcwg-special
15:34:01 <selfissued_> q+
15:34:04 <DavidC> what about bindingMethod
15:34:06 <dmitriz> +1, I agree w/ Joe's & Dave's points.
15:34:09 <TallTed> Also from https://www.rfc-editor.org/rfc/rfc7800.html "Another means used by some applications to identify the presenter is an explicit claim, such as the "azp" (authorized party) claim defined by OpenID Connect [OpenID.Core].  Ultimately, the means of identifying the presenter is application specific, as is the means of confirming possession of the key that is communicated."
15:34:13 <TallTed> q+
15:34:17 <JoeAndrieu_> kristina: can we replace the name for the moment, as a TBD?
15:34:21 <kristina_> ack selfissued_
15:34:34 <JoeAndrieu_> selfissued: Nothing is said in anything about confirming claims
15:34:40 <JoeAndrieu_> q+ to say its not about claims
15:34:49 <JoeAndrieu_> ... I don't know what Dave is referring to.
15:34:56 <oliver> +1 mike
15:34:59 <kristina_> ack TallTed
15:35:00 <dmitriz> it's not that there was literature, it's that there's a common confusion about it
15:35:22 <JoeAndrieu_> tallted: I have problems with the idea that we cannot mint our own terms for things that are appropriate to the stuff we are specifying
15:35:36 <JoeAndrieu_> ... I don't care about what previous groups did, except where it is exactly what we are doing
15:35:46 <JoeAndrieu_> ... Just looking at the cnf discussion in the JWT RFC
15:35:58 <JoeAndrieu_> ... It says lots of stuff, including other terms that are similar, but not the same.
15:36:14 <JoeAndrieu_> ... There's no reason we shouldn't have our own term for things that are, not the same
15:36:24 <JoeAndrieu_> ... This started out as "holder binding"
15:36:34 <JoeAndrieu_> ... I've had issues with that since it was first brought upt
15:36:50 <JoeAndrieu_> ... VCs are not bound to a holder or subject. They are not BOUND to anything.
15:36:56 <kristina_> but there is nothing normative in this PR related to the cnf method in rfc 7800
15:37:16 <JoeAndrieu_> ... It may include statements about the issuee or the authorized holder.
15:37:32 <JoeAndrieu_> ... It seems that only JOE is the authorized presenter
15:37:38 <DavidC> q+
15:37:45 <JoeAndrieu_> ... Why don't we use that term authorizedPresenter
15:37:53 <pdl_ASU> I think it's important that the language we adopt is broadly understood, rather than understood by a group that has been working in this space for some. Hence, +1 to Dmitri's comment, and +1 TallTed's suggestion.
15:37:55 <oliver> q+
15:38:32 <JoeAndrieu_> tallted: I prefer confidenceMethod
15:38:49 <JoeAndrieu_> ... confirmation has definiteness and confidence is less definite
15:38:55 <kristina_> ack JoeAnrieu_
15:38:58 <kristina_> ack JoeAnrieu
15:39:26 <dlongley> JoeAndrieu_: I just want to respond to Mike's comments. I don't think Dave or I are talking about the veracity of the claims -- Dave mentioned that about confusion. I was talking about what do you get when you check IP / crypto / etc. all you're doing is confirming the crypto. That's it.
15:39:53 <dlongley> JoeAndrieu_: There's always a potential misalignment there when keys are stolen or whatever. What you can do is increase confidence, you can't ever confirm.
15:40:03 <kristina_> ack DavidC
15:40:05 <dlongley> JoeAndrieu_: You can't confirm who is presenting the VC is who you think it is, but you can increase your confidence.
15:40:06 <mprorock> q+
15:40:12 <TallTed> +1 Joe's comments
15:40:13 <kristina_> ack JoeAndrieu_
15:40:13 <Zakim> JoeAndrieu_, you wanted to say its not about claims
15:40:16 <dlongley> +1 to Joe
15:40:20 <JoeAndrieu_> DavidC: when we go back to original definition, it was "holder binding" isn't it
15:40:41 <JoeAndrieu_> ... that's what we want. binding. The verifier wants to know if the presenter is the person it was given to
15:40:45 <TallTed> it's still not binding
15:40:48 <TallTed> q+
15:40:50 <JoeAndrieu_> ... The verifiers want to bind
15:41:07 <dlongley> +1 to TallTed, you can't "bind" a person like that
15:41:07 <dmitriz> dmitriz has joined #vcwg-special
15:41:19 <kristina_> ack oliver
15:41:19 <JoeAndrieu_> kristina: I appreciate the strong opinions. We have nearly 20 PRs open and blocked.
15:41:26 <JoeAndrieu_> ... can we consider compromises?
15:42:03 <JoeAndrieu_> oliver: what do people think of renaming to confidenceMethod with language explaining its relation to confirmation methods as used in other specs
15:42:05 <dlongley> +1 to Oliver to make it possible to map `cnf` to a subset of confidence methods
15:42:26 <dlongley> +1 to Oliver's proposal
15:42:27 <pdl_ASU> +1 to confidenceMethod
15:42:30 <kristina_> ack mprorock
15:42:30 <JoeAndrieu_> ... the proposal is to use confidenceMethod but make it clear that confirmationMethod, cnf, is included in that superset
15:42:51 <JoeAndrieu_> mprorock: XKCD 927 about competing standards
15:43:19 <JoeAndrieu_> ... this is a little bit of a trap. we need to be careful with our language. VCs don't verify truth.
15:43:50 <JoeAndrieu_> ... however, it is increasingly difficult when talking with folks at NIST or people who live in that language, when we have to explain why there is a new term for something similar
15:44:18 <JoeAndrieu_> ... JWTs define cnf for confirmation claims. can we improve on that? Yes
15:44:24 <JoeAndrieu_> ... What we are doing is similar
15:44:30 <JoeAndrieu_> ... So let's call it an expansion of that
15:44:53 <dlongley> +1 to Oliver's proposal because it covers MikeP's point, people interested in `cnf` can just read that section, plus we get improvements
15:44:55 <dlongley> q+
15:44:55 <JoeAndrieu_> ... I really get concerned from the lack of perfection in our semantics.
15:45:13 <JoeAndrieu_> ... But the reality is whether it is better language or not, that's not how the rest of the industry works
15:45:35 <JoeAndrieu_> ... Let's not let the perfect be the enemy of the good. This is a work in progress
15:46:10 <TallTed> "By including a "cnf" (confirmation) claim in a JWT, the issuer of the JWT declares that the presenter possesses a particular key and that the recipient can cryptographically confirm that the presenter has possession of that key."
15:46:14 <JoeAndrieu_> ... cnf is broadly in use. But it's not the end of the world if we have slightly different language, but if we can pick that which aligns, let's try to do that
15:46:30 <kristina_> ack TallTed
15:46:31 <JoeAndrieu_> kristina: would anyone be opposed to keeping confirmationMethod while we open an issue
15:46:35 <dlongley> let's offer a different propsal, which is oliver's
15:46:45 <JoeAndrieu_> TallTed: I just pasted from the JWT RFC
15:47:07 <JoeAndrieu_> ... with the language of CNF. It is not the vagueness that people are speaking of. It is very specific.
15:47:26 <JoeAndrieu_> ... it does not say biometrics, IP, or ouiji board.
15:47:39 <selfissued_> q+
15:47:45 <JoeAndrieu_> ... If we are going to use an industry term, we better make sure we are aligned with that term
15:48:17 <JoeAndrieu_> ... DavidC, going back to your original language doesn't help us move forward
15:48:21 <mprorock> q?
15:48:44 <JoeAndrieu_> TallTed: If you have issue with my word choice, please be explicit and I'll do my best to modify
15:48:57 <mprorock> i would like to note that i use of "confirmation" in this case would be a similar extension to cnf as is used elsewhere
15:49:11 <JoeAndrieu_> ... what is being asked for, was a way to ensure that only explicitly identified parties are authorized/permitted to present a credential.
15:49:38 <JoeAndrieu_> ... that is not confirmationMethod or even confidenceMethod, even though I like that latter because it can be used more flexibly.
15:49:42 <oliver> q+
15:49:46 <kristina_> ack dlongley
15:49:54 <JoeAndrieu_> dlongley: I think we should run something like Oliver's proposal.
15:49:54 <oliver> q-
15:50:30 <JoeAndrieu_> ... it gives us a generic name. it solves mprock's problem so we can fit in the CNF relationship. so government folks using it as common. And we can use it as we need to.
15:50:45 <JoeAndrieu_> ... We should be careful about deferring our decision to memes, as funny as they might be
15:50:53 <kristina_> ack selfissued_
15:50:53 <oliver> q+
15:51:27 <JoeAndrieu_> selfissued_: To Ted's point about whether the things are general, there is language in the RFC that says that
15:51:38 <JoeAndrieu_> ... if you go to the SAML spec, you will see IP address an other stuff.
15:52:01 <JoeAndrieu_> kristina: Ok, do we want a proposal or a poll?
15:52:11 <JoeAndrieu_> brent: I'd like a poll first
15:52:27 <JoeAndrieu_> kristina: ok, let's try a poll
15:52:52 <oliver> q+
15:52:59 <kristina_> ack oliver
15:53:04 <selfissued_> Yes, cnf applies
15:53:25 <JoeAndrieu_> oliver: Perhaps we have two proposals. First: PR as confirmationMethod with TBD language for renaming
15:53:36 <TallTed> "The case in which the presenter is the subject of the JWT is analogous to Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation usage." *"Analogous"*, not "the same". Also, specifically about when presenter=subject.
15:53:40 <kristina_> poll: merge PR as-is (confirmation method), while open a PR that we are bikeshedding.
15:53:43 <JoeAndrieu_> ... Second, find a term that makes most people happy and adapt the language to accomodate IETF
15:54:00 <dlongley> -1 to merge as-is, let's rename and then merge
15:54:01 <oliver> +1
15:54:03 <JoeAndrieu_> -1
15:54:07 <andres> -1
15:54:07 <selfissued_> +1
15:54:07 <brent> +1
15:54:12 <DavidC> +1
15:54:12 <mprorock> +1
15:54:12 <TallTed> -1 as dlongley
15:54:15 <shigeya> -1
15:54:17 <pdl_ASU> -1
15:54:40 <dmitriz> -0 (there's tended to be more inertia to changing existing)
15:54:44 <JoeAndrieu_> kristina: ok. second poll
15:54:51 <kristina_> poll: renaming to confidenceMethod with language explaining its relation to confirmation methods as used in other specs
15:54:57 <oliver> +1
15:54:57 <dlongley> +1
15:55:00 <JoeAndrieu_> +1
15:55:00 <selfissued_> -1
15:55:03 <TallTed> merging as-is runs strong risk of sticking, because inertia happens (he typed before seeing dmitriz comment)
15:55:05 <pdl_ASU> +1
15:55:09 <dmitriz> +1
15:55:10 <andres> +1
15:55:11 <will> +1
15:55:12 <DavidC> 0
15:55:14 <TallTed> +1
15:55:14 <shigeya> 0
15:55:17 <mprorock> -0
15:55:51 <JoeAndrieu_> kristina: Ok, we have only one minus one. Mike, is this a formal objection matter for you?
15:55:56 <brent> +1
15:56:05 <JoeAndrieu_> selfissued_: No. I just want what we do to make sense.
15:56:08 <mprorock> q+
15:56:13 <kristina_> ack mprorock
15:56:37 <JoeAndrieu_> mprorock: For the record, I am -0 because I want to see the group move forward. I disagree with the approach, but want us to move forward.
15:57:06 <JoeAndrieu_> ... we are going to map that directly to cnf, so why not start with that?
15:57:08 <DavidC> in ACDC discussion 0's were taken as not-concensus, rather than don't care. We ought to be consistent in what 0 means
15:57:11 <JoeAndrieu_> ... but I don't want o block on that
15:57:13 <dmitriz> proposal: rename JWT's 'cnf' claim to Confidence claim :)
15:57:27 <dmitriz> (sorry, not formal proposal)
15:57:39 <JoeAndrieu_> kristina if we change this to confidenceMethod, does it clear your block, Dave Longley?
15:57:55 <JoeAndrieu_> ... if folks feel strongly, please create a new issue
15:58:17 <JoeAndrieu_> ... There is manu's request for changes. Have these been addressed?
15:58:29 <JoeAndrieu_> mprorock: those changes have been addressed
15:58:51 <JoeAndrieu_> TallTed: I can't say if my issues have been address. I need to review the whole thing
15:59:03 <JoeAndrieu_> kristina: ok. thank you everyone.
15:59:10 <JoeAndrieu_> ... two points:
15:59:31 <JoeAndrieu_> ... Zoom URL will be new starting next week. Tomorrow is still the MIT one. But from the next will be the new one.
15:59:55 <JoeAndrieu_> second point: we have 20 prs in VC data model and 10 are labelled DO NOT MERGE
16:00:20 <JoeAndrieu_> ... This is undesirable. Please consider when you are willing to compromise and when you need to fight
16:00:27 <JoeAndrieu_> ... Please be mindful
16:00:34 <JoeAndrieu_> ... See you tomorrow!
16:11:26 <kristina_> rrsagent, draft minutes
16:11:28 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/02-vcwg-special-minutes.html kristina_
16:11:34 <kristina_> zakim, end meeting
16:11:34 <Zakim> As of this point the attendees have been DavidC, ivan, shigeya, mprorock, kristina, identitywoman, selfissued, olvier, brent, dlongley, markus_sabadello, andres, Phil-ASU,
16:11:37 <Zakim> ... jandrieu, oliver, abramson, JoeAndrieu_, pdl_ASU, dmitriz, kristina_, TallTed, selfissued_
16:11:37 <Zakim> RRSAgent, please draft minutes
16:11:38 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/02-vcwg-special-minutes.html Zakim
16:11:40 <Zakim> I am happy to have been of service, kristina_; please remember to excuse RRSAgent.  Goodbye
16:11:42 <kristina_> rrsagent, bye
16:11:44 <Zakim> Zakim has left #vcwg-special
16:12:02 <kristina_> rrsagent, goodbye
16:12:02 <RRSAgent> I'm logging. I don't understand 'goodbye', kristina_.  Try /msg RRSAgent help
16:12:07 <kristina_> rrsagent, bye
16:13:35 <kristina_> rrssagent, make logs public
16:13:57 <kristina_> rrssagent, bye
16:14:12 <kristina_> rrsagent, make logs public
16:14:19 <kristina_> rrsagent, bye
16:14:19 <RRSAgent> I see no action items