22:53:53 <RRSAgent> RRSAgent has joined #vcwg-special
22:53:57 <RRSAgent> logging to https://www.w3.org/2023/01/17-vcwg-special-irc
22:54:00 <brent> zakim, start the meeting
22:54:00 <Zakim> RRSAgent, make logs Public
22:54:01 <Zakim> please title this meeting ("meeting: ..."), brent
22:54:14 <brent> meeting: vcwg special topic call
22:54:21 <brent> chair: Brent
22:57:02 <mprorock> mprorock has joined #vcwg-special
23:01:42 <Kerri_Lemoie> Kerri_Lemoie has joined #vcwg-special
23:03:05 <manu> manu has joined #vcwg-special
23:03:10 <manu> present+
23:03:11 <Orie> Orie has joined #vcwg-special
23:03:13 <Orie> present+
23:03:15 <selfissued> selfissued has joined #vcwg-special
23:03:26 <selfissued> present+
23:03:28 <selfissued> scribe+
23:03:58 <JoeAndrieu> JoeAndrieu has joined #vcwg-special
23:04:01 <brent> present+
23:04:05 <Phil-ASU> Phil-ASU has joined #vcwg-special
23:04:10 <dlongley> present+
23:04:10 <Phil-ASU> present+
23:04:10 <mprorock> present+
23:04:14 <Kerri_Lemoie> present+
23:04:30 <selfissued> Orie:  Any objections to merging PR #1000?
23:04:35 <Orie> https://github.com/w3c/vc-data-model/pull/1000
23:05:14 <Phil-ASU> +1 for merging
23:05:15 <selfissued> Kristina: I think we should merge it.
23:05:21 <dlongley> +1 to merging
23:05:21 <JoeAndrieu> present+
23:05:41 <selfissued> Orie: There are more approvals than I've seen on any PR since we resumed working.
23:05:50 <dwaite> dwaite has joined #vcwg-special
23:05:57 <selfissued> ... There were change requests that were accepted, which became approvals.
23:05:59 <dwaite> present+
23:06:09 <selfissued> brent: Please give us a summary
23:06:12 <Kerri_Lemoie> Yes - overview would be helpful.
23:06:24 <selfissued> ... If there are no objections, I believe it would be appropriate to merge it
23:06:49 <shigeya_> shigeya_ has joined #vcwg-special
23:07:03 <selfissued> Orie: A credential becomes a Verifiable Credential when it contains an embedded or external proof
23:07:04 <shigeya_> present+ shigeya
23:07:13 <brent> zakim, who is here?
23:07:13 <Zakim> Present: manu, Orie, selfissued, brent, dlongley, Phil-ASU, mprorock, Kerri_Lemoie, JoeAndrieu, dwaite, shigeya
23:07:15 <Zakim> On IRC I see shigeya_, dwaite, Phil-ASU, JoeAndrieu, selfissued, Orie, manu, Kerri_Lemoie, mprorock, RRSAgent, Zakim, brent, dlongley, dlehn, stenr, csarven
23:07:35 <selfissued> ... The media type describes this core data model type without or possibly with a proof
23:07:49 <selfissued> ... We can take a step closer to resolving ambiguity in the specification
23:08:23 <brian> brian has joined #vcwg-special
23:08:28 <selfissued> ... We can use this content-type to describe the content that is secured in the specification
23:08:40 <selfissued> ... There are two proof formats in the spec: embedded and external
23:09:01 <selfissued> ... Data integrity proofs use embedded, VC-JWTs use external
23:09:16 <selfissued> ... The purpose of this PR is to describe the thing that we're securing
23:09:33 <selfissued> ... It can become a Verifiable Credential by securing it
23:09:44 <decentralgabe> decentralgabe has joined #vcwg-special
23:09:48 <decentralgabe> q+
23:09:51 <decentralgabe> present+
23:09:51 <selfissued> ... Having a media type gives us a way to talk about what it is
23:09:57 <selfissued> selfissued: Merge it
23:10:04 <brent> ack decentralgabe
23:10:07 <brian> present+
23:11:17 <manu> q+ to attempt to answer the question in the abstract with my ietf-mediaman-media-type-suffixes Editor hat on.
23:12:28 <brent> ack manu
23:12:28 <Zakim> manu, you wanted to attempt to answer the question in the abstract with my ietf-mediaman-media-type-suffixes Editor hat on.
23:12:44 <kristina> kristina has joined #vcwg-special
23:12:46 <selfissued> manu: The only thing that prevents divergence is talking to one another across the specs
23:12:49 <kristina> present+
23:13:03 <mprorock> +1 manu - editor comms, working group eyes - same as any other media type or external pointer (e.g. to alg combinations)
23:13:06 <selfissued> ... It's always possible to register too many media types or create non-interoperability
23:13:08 <brent> present+ brian
23:13:12 <selfissued> ... We need to talk to one another
23:13:42 <selfissued> ... When there are other media types, we need to ensure that they're aligned with our philosophy across the specifications
23:13:50 <mprorock> q+
23:13:55 <brent> ack mprorock
23:13:56 <selfissued> ... If they diverge, they need to do so for very good reasons
23:14:24 <selfissued> mprorock: There's an important lesson from this PR.  The quickness of its approval indicates that this was needed.
23:14:46 <selfissued> ... If things get fuzzy later, at that point we can step back
23:15:04 <selfissued> ... For this one, we quickly got to something useful
23:15:48 <selfissued> brent: At this stage, we first wanted to talk about PR 1000
23:16:05 <selfissued> ... We have a lot of approvals. It would be entirely appropriate to merge it.
23:17:05 <selfissued> manu: Please provide something for the disposition comments when you merge things.
23:17:19 <Orie> q+
23:17:19 <selfissued> ... I will add the disposition comments
23:17:30 <selfissued> brent: Can the associated issues be closed?
23:17:39 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/978
23:17:45 <selfissued> ... Let's look at #978 first
23:17:48 <brent> ack Orie
23:18:14 <selfissued> ... I raised this issue.  I believe this can be closed now that PR #1000 has been merge.
23:18:30 <selfissued> brent: You can indicate that since PR #1000 was merged, this can be closed
23:18:39 <selfissued> Orie: The issue is now closed
23:19:21 <manu> q+ to remind the group about our merge rules.
23:19:26 <mprorock> depends on length of time open, and sufficient working group input in my mind, which was definitely the case for #1000
23:19:33 <selfissued> brent: Tony asked in the Zoom chat if it wouldn't have been more appropriate to merge during a main call
23:19:50 <brent> ack manu
23:19:50 <Zakim> manu, you wanted to remind the group about our merge rules.
23:19:56 <selfissued> ... The PR already met criteria for being merged.  We merge things not only during calls.
23:20:23 <selfissued> manu: Our work mode is that if it's been open for 7 days and there are no objections, it's fine to merge things.
23:20:28 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/421
23:20:37 <Orie> q+
23:20:58 <selfissued> brent: Issue #421 by Daniel Hardman may be relevant
23:21:08 <brent> ack Orie
23:21:18 <selfissued> ... Does merging PR #1000 address the media type concerns raised in #421
23:21:27 <selfissued> Orie: There are additional things to be done
23:21:38 <selfissued> ... Maybe this issue can be closed in the core data model
23:22:01 <selfissued> ... There are additional media types being considered for registration
23:22:13 <manu> q+ to suggest closing the PR -- open a more specific PR for a new media type if you want it.
23:22:50 <dlongley> +1 to closing #421 and open any new issues if new media types are required
23:22:54 <brent> ack manu
23:22:54 <Zakim> manu, you wanted to suggest closing the PR -- open a more specific PR for a new media type if you want it.
23:23:01 <manu> q-
23:23:01 <selfissued> Orie: I believe the WG should close #421 until such time as there is a new media type being requested for registration in the core data model
23:23:01 <mprorock> +1 to closing issue #421
23:23:14 <manu> +1 to close issue #421
23:23:14 <selfissued> manu: _1 to what Orie said
23:23:20 <Phil-ASU> +1 agreed here
23:23:24 <manu> s/_1 to what/+1 to what/
23:23:58 <selfissued> brent: Considering that the scribe's text will appear as a comment on the issue, I will wait for that and then close it.
23:24:00 <manu> q+
23:24:09 <brent> ack manu
23:24:16 <decentralgabe> q+ to ask what implications media types have on different representations (data integrity, vc-jwt)
23:24:41 <selfissued> manu: There is a PR on VC-
23:25:18 <selfissued> ... ... VC-JWT requesting a new media type registration
23:25:42 <selfissued> ... Do we want to specify what happens when people use the wrong media type?
23:25:49 <selfissued> ... Such as application/json
23:25:50 <mprorock> +1 manu on the application/verifiable+credential, as well as especially the application/json issue
23:26:10 <selfissued> ... We have evidence that people ignore media types
23:26:16 <brent> ack decentralgabe
23:26:16 <Zakim> decentralgabe, you wanted to ask what implications media types have on different representations (data integrity, vc-jwt)
23:26:40 <selfissued> gabe: What implications does a media type have on the representation of the credential?
23:26:54 <manu> q+ to "please no different sections for different media types"
23:27:00 <brent> ack manu
23:27:00 <Zakim> manu, you wanted to "please no different sections for different media types"
23:27:02 <selfissued> ... Will there be separate sections of the spec for different media types and/or separate specifications?
23:27:32 <selfissued> manu: We could really screw up by adding too many media types
23:27:56 <selfissued> ... Developers could get upset at us for making things too complicated
23:28:11 <selfissued> ... CBOR and YAML media types could exist in the future
23:28:22 <selfissued> ... CBOR-LD is already in use
23:28:38 <selfissued> ... We don't have to change any language in the spec for those media types to exist
23:28:58 <selfissued> ... Those already implement the existing VC Data Model
23:29:18 <selfissued> ... Looking at PRs and issues will help guide us
23:29:27 <brent> subtopic: https://github.com/w3c/vc-jwt/pull/40
23:29:35 <selfissued> brent: Next we will look at VC-JWT PR #40
23:30:05 <selfissued> Orie: Now that we've merged PR #1000, we have a media type describing a credential without a proof
23:30:37 <selfissued> ... There's been commentary on the list for using the media type that we registered
23:30:58 <Orie> These proposals need to be updated to use our new media type: https://github.com/w3c/vc-data-model/pull/1000#discussion_r1065931004
23:31:10 <selfissued> Orie: These proposals need to be updated to use the new media type
23:31:35 <selfissued> ... In JWTs there are two fields that are relevant to the media type:  "cty" and "typ"
23:32:04 <selfissued> ... In VC-JWT PR #40, we define a media type for a VC-JWT 1.1 Claims Set
23:32:28 <selfissued> ... The one that includes "iss", "sub", "vc", etc.
23:32:58 <selfissued> ... This media type defines a VC-JWT credential that will have an external proof
23:33:11 <selfissued> ... The "cty" and "typ" properties are different
23:33:26 <selfissued> ... This PR is to define the content type
23:33:41 <manu> q+
23:33:49 <brent> ack manu
23:33:50 <mprorock> +1 orie - that distinction between payload and otherwise is important
23:33:54 <selfissued> manu: This PR confused me
23:34:08 <selfissued> ... I think I followed what you were saying, Orie
23:34:34 <mprorock> +1 cty
23:34:36 <selfissued> ... I looked at other RFCs that defined media types
23:34:38 <dlongley> q+
23:34:58 <selfissued> ... These seem to be using the +jwt suffix
23:35:04 <mprorock> version hurts me
23:35:13 <selfissued> Orie: This is for "cty" - not "typ"
23:35:38 <selfissued> ... We're versioning it because we're pretty unhappy with the 1.1 claims set
23:35:43 <manu> +1, the payload format for VC-JWT is observably bad and has led to non-interoperable implementations.
23:35:50 <mprorock> q+ to ask re versioning
23:35:58 <selfissued> ... In particular, the instead-of vs. in-addition-to
23:36:14 <selfissued> ... We wanted to have a "cty" to refer to 1.1
23:36:28 <decentralgabe> no mention of cty/typ in https://transmute-industries.github.io/vc-jws
23:36:37 <selfissued> ... We expect developers to switch on the media type
23:36:48 <selfissued> ... How it's going to be versioned is subject to debate
23:37:00 <selfissued> ... For instance, there could be parameters
23:37:08 <brent> ack dlongley
23:37:10 <dlongley> https://github.com/w3c/vc-jwt/pull/40#discussion_r1072663183
23:37:13 <selfissued> ... But for sure, they are going to be versioned
23:37:16 <selfissued> q+
23:37:46 <selfissued> dlongley: RFC 7519 recommends against using "cty" for a JWT
23:38:23 <selfissued> Orie: I've read that section of the RFC and was similarly confused by it
23:38:42 <selfissued> ... I've seen developers use "cty" in the wild to describe the content
23:39:11 <selfissued> ... In COSE_Sign1, I've seen code productively switch on "cty"
23:39:38 <selfissued> ... When RFCs are written, sometimes later things are used differently than originally intended
23:39:47 <brent> ack mprorock
23:39:47 <Zakim> mprorock, you wanted to ask re versioning
23:39:48 <manu> q+ to note that we will probably want to say something like "This media type is expected to be used in conjunction with `cty` and NOT as a general content type for Accept/Content-Type?"
23:39:57 <selfissued> ... In COSE_Sign1, cty is used to protect other kinds of content
23:40:13 <selfissued> mprorock: cty is used to actively switch on content
23:40:20 <selfissued> ... I did approve this PR
23:40:43 <selfissued> ... The only thing that makes me uncomfortable is the versioning, but we clearly do have to version
23:40:52 <dlongley> seems like we need some kind of "this is a JWT claim set" in the media type name ... because it's not just a credential from the VCDM 1.1 ... it's a credential in a claims set in the "vc" claim :/
23:41:00 <mprorock> scribe+
23:41:05 <selfissued> ... I would not let versioning being imperfect block us from merging this
23:41:08 <decentralgabe> scribe+
23:41:08 <mprorock> scribe-
23:41:11 <brent> scribe+ decentralgabe
23:41:25 <brent> ack selfissued
23:41:36 <decentralgabe> selfissued: I wrote that text in 7519..over a decade ago, different environment. since then, JWTs succeeded. used for all types of things we never imagined. secure caller id, others
23:42:15 <decentralgabe> ... because of them succeeding IETF asked for a 'best current practices doc' on how to best securely use them. main thing added was strongly typing JWTs. for the `typ` field. used to prevent "cross-JWT-confusion"
23:42:43 <decentralgabe> ... also appropriate to strongly type the content. only imagined there being one `typ` for a JWT, which is 'JWT' but the world has changed
23:43:00 <decentralgabe> ... practice is now on switching on the cty property. unconcerned about violating spec text. it is obsolete
23:43:34 <mprorock> +1 let's make some progress!
23:43:39 <decentralgabe> ... agree with mprorock. versioning may not be perfect. can refine it. more important to put a stake in the ground, refine something that's versioned. this is a first attempt. shouldn't stand in the way of merging
23:43:44 <decentralgabe> scribe-
23:43:46 <dlongley> q+ to say `credential-1.1+json` seems like it could be confused with a credential that isn't in a JWT claim set
23:44:16 <selfissued> brent: I will note that JWT-VC PR #40 is not in the same position of PR #1000
23:44:20 <brent> ack manu
23:44:20 <Zakim> manu, you wanted to note that we will probably want to say something like "This media type is expected to be used in conjunction with `cty` and NOT as a general content type for
23:44:23 <Zakim> ... Accept/Content-Type?"
23:44:26 <brent> q+ nadalin
23:44:39 <selfissued> ... There is a change request that still needs to be resolved
23:45:01 <selfissued> manu: We keep saying that this will only be used with "cty", but that may not be true
23:45:11 <selfissued> ... We currently aren't saying anything about "cty" in the spec
23:45:37 <selfissued> ... If this is going to be used more broadly, we need to describe how
23:45:52 <Orie> q+ to note that there is still disambiguity when version is removed.
23:46:06 <selfissued> ... If you remove the version it starts to look like we have a conflict between the processing for the two media types
23:46:23 <selfissued> ... The PR doesn't say anything about it being a JWT Claims Set
23:46:42 <selfissued> ... If this is expressing a Claims Set, it should say so
23:46:55 <selfissued> ... Can this go in "typ"?  Is it forbidden to be in "typ"?
23:46:59 <brent> ack dlongley
23:46:59 <Zakim> dlongley, you wanted to say `credential-1.1+json` seems like it could be confused with a credential that isn't in a JWT claim set
23:47:12 <selfissued> ... We need to get answers to these questions before we merge it
23:47:32 <selfissued> dlongly: I'd like to see Claims Set in the name
23:47:37 <selfissued> q+
23:47:44 <brent> ack nadalin
23:48:02 <selfissued> Tony: I'm trying to understand if "cty" is going to mandatory
23:48:04 <brent> ack Orie
23:48:04 <Zakim> Orie, you wanted to note that there is still disambiguity when version is removed.
23:48:19 <selfissued> Orie: We don't know yet
23:48:22 <mprorock> q+ to ask manu about suitability of those items in the iana section
23:48:31 <selfissued> ... We didn't answer the similar questions when we merged PR #1000
23:48:38 <selfissued> ... This is specific to "cty"
23:48:45 <manu> q+ to note that just because it's in vc-jwt doesn't mean "there are only two places it should go".
23:48:48 <selfissued> ... This is based on the BCP for JWTs
23:49:07 <selfissued> ... I don't think it's necessary to add all those paragraphs of text before merging the PR
23:49:12 <dlongley> `{"vc": "..."}` <-- is not a "credential" in the VCDM, i think this is the point of confusion
23:49:39 <selfissued> ... My gut is that it doesn't need to be required because it's not in current 1.1 VC-JWTs
23:49:58 <kristina> my gut would be say it is recommended to put a cty and define a de fault behavior when it is not present
23:50:14 <mprorock> manu/dave - see https://github.com/w3c/vc-jwt/pull/40/files#r1072950447
23:50:19 <brent> q?
23:50:25 <mprorock> does that work?
23:50:33 <kristina> and guess it will apply to both cty and typ eg recommendation & de fault
23:50:37 <selfissued> ... It's OK to uniquely identify the structured data element before we completely describe it
23:50:48 <dlongley> no, the name should reflect that it's a claimset not a credential
23:50:49 <selfissued> ... Doing it the beginning helps us separate 1.1 and 2.0 ideas
23:50:49 <dlongley> q+
23:51:00 <decentralgabe> scribe+
23:51:03 <brent> ack selfissued
23:51:23 <mprorock> q-
23:51:46 <decentralgabe> selfissued: Very good question from dlongley and others. why not claimset? in the same way we recommend specific content types that are specific as possible for typ. we want to use as specific as possible for cty, for the body, to prevent confusion
23:52:25 <decentralgabe> ... everything that is a jwt could have a content type of claim set. did not both defining it for the JWT. did not add value. defining claimset identifier that's a credential (albeit unsecured) does add value. says things about the content type
23:52:25 <Orie> +1 selfissued, i think using "claimSet" in a cty is sort-of redundant.
23:52:28 <decentralgabe> scribe-
23:52:33 <brent> ack manu
23:52:33 <Zakim> manu, you wanted to note that just because it's in vc-jwt doesn't mean "there are only two places it should go".
23:52:43 <mprorock> +1 selfissued
23:52:46 <dlongley> q+ to say why not just use the other media type we just defined then?
23:52:59 <selfissued> manu: That didn't go were I thought Mike was going
23:53:11 <selfissued> ... People will look at the registry and use it in different place
23:53:36 <Orie> q+ this is the media type we have in the spec today, for 1.1...
23:53:42 <Orie> q+ to say this is the media type we have in the spec today, for 1.1...
23:53:59 <selfissued> ... Orie said that we already merged something with ambiguity but that doesn't mean that we need to merge another thing with ambiguity
23:54:03 <brent> q?
23:54:11 <brent> ack dlongley
23:54:11 <Zakim> dlongley, you wanted to say why not just use the other media type we just defined then?
23:54:22 <selfissued> ... We need to ensure that this is not confused with the VC Data Model
23:54:51 <Orie> please read the proposals that have gone to the list... and compare to what we have shipped in 1.1
23:55:00 <selfissued> dlongley: We're talking about two different JSON data objects: One is a credential - one is a Claims Set
23:55:02 <mprorock> +1 proe
23:55:08 <mprorock> +1 orie
23:55:10 <selfissued> ... Those things don't line up to me
23:55:14 <selfissued> q+
23:55:18 <mprorock> this has been detailed on the list and in 1.1
23:55:20 <manu> I have read the proposals, this part of it doesn't make sense.
23:55:26 <brent> Ack Orie
23:55:26 <Zakim> Orie, you wanted to say this is the media type we have in the spec today, for 1.1...
23:55:33 <selfissued> ... If we include in the name that it's a Claims Set, then the confusion goes away
23:55:48 <selfissued> ... This defines a media type for what we've shipped in 1.1
23:56:00 <selfissued> ... In 1.1, you can secure with an external proof
23:56:03 <manu> q+
23:56:17 <selfissued> ... When using an external proof, this gives you a media type to refer to the secured body
23:56:23 <manu> ok, so this isn't just for cty... this is for "The media type for VCDM v1.1"
23:56:31 <brent> q?
23:56:56 <selfissued> ... You can declare that this is 100% compatible with 1.1 VC-JWT with this cty
23:56:59 <dlongley> does "cty": "application/credential-1.1+json" ... mean you should expect: `{"vc": ...}` ... as the payload?
23:57:02 <mprorock> re: ok, so this isn't just for cty... this is for "The media type for VCDM v1.1 in cty in a jwt"
23:57:09 <manu> q+ to note then that this isn't about cty, this is about establishing a VCDM v1.1 media type
23:57:23 <brent> ack selfissued
23:57:28 <manu> mprorock, that's not clear at all from the PR or from what is being said.
23:58:18 <brent> selfissued: I'm fine adding the clarifying comments folks are asking for. Only intended for 'cty' and we could add it is a media type for a jwt claim set as defined by 1.1 VC JWT section
23:58:24 <Orie> +1 selfissued
23:58:32 <brent> ... byt am opposed to adding redundant stuff to the name
23:58:36 <mprorock> does this text work? https://github.com/w3c/vc-jwt/pull/40#discussion_r1072950447
23:58:38 <manu> q?
23:58:40 <brent> ack manu
23:58:40 <Zakim> manu, you wanted to note then that this isn't about cty, this is about establishing a VCDM v1.1 media type
23:58:49 <selfissued> manu: I'm hearing multiple things being said
23:58:55 <dlongley> couldn't "application/credential-1.1+json" be confused with `{"id": vc_id, ...}` ?
23:59:08 <dlongley> i mean, i fully expect developers to make that mistake
23:59:21 <mprorock> i have suggested text to clarify these items - please comment on the PR
23:59:22 <selfissued> ... I've heard that this isn't just for VC-JWTs
23:59:46 <selfissued> Orie: This media type is intended to define the payload of a VC-JWT 1.1
23:59:54 <selfissued> ... Claims Set - not a "typ"
00:00:09 <selfissued> brent: I think this was a very productive call
00:00:27 <dlongley> i support a media type for this ... i just think the naming is confusing right now :)
00:00:27 <selfissued> ... Please continue conversation in VC-JWT PR #40
00:00:35 <selfissued> ... Thanks everybody!
00:00:39 <brent> zakim, who is here?
00:00:39 <Zakim> Present: manu, Orie, selfissued, brent, dlongley, Phil-ASU, mprorock, Kerri_Lemoie, JoeAndrieu, dwaite, shigeya, decentralgabe, brian, kristina
00:00:40 <Kerri_Lemoie> Thanks!
00:00:41 <Zakim> On IRC I see kristina, shigeya_, dwaite, Phil-ASU, JoeAndrieu, selfissued, Orie, manu, Kerri_Lemoie, mprorock, RRSAgent, Zakim, brent, dlongley, dlehn, stenr, csarven
00:00:59 <brent> zakim, end the meeting
00:00:59 <Zakim> As of this point the attendees have been manu, Orie, selfissued, brent, dlongley, Phil-ASU, mprorock, Kerri_Lemoie, JoeAndrieu, dwaite, shigeya, decentralgabe, brian, kristina
00:01:02 <Zakim> RRSAgent, please draft minutes
00:01:04 <RRSAgent> I have made the request to generate https://www.w3.org/2023/01/17-vcwg-special-minutes.html Zakim
00:01:11 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
00:01:11 <Zakim> Zakim has left #vcwg-special
00:01:18 <brent> rrsagent, bye
00:01:18 <RRSAgent> I see no action items