Dereferencing relative to issuer

[OR13]

We should add guidance somewhere regarding dereferencing relative to an issuer.

See also decentralized-identity/ion#285

For example:

issuer + proof.verificationMethod => { publicKeyJwk }
iss + kid => { publicKeyJwk }

[peacekeeper]

This should be consistent with standard URI "relative resolution" as explained in https://datatracker.ietf.org/doc/html/rfc3986#section-5.2.

[brentzundel]

How is this related to #709

[OR13]

See also https://github.com/decentralized-identity/did-jose-extensions/blob/master/options.md

[OR13]

proof.verificationMethod MUST be an absolute IRI to a verificationMethod.

kid MUST be a relative IRI, relative to iss, to a verificationMethod.

[OR13]

Related to the "controller" is "issuer" comment that Manu made regarding Data Integrity.

https://github.com/digitalbazaar/vc-js/blob/main/lib/CredentialIssuancePurpose.js#L72

[dlongley]

One option is to make it so that if you dereference the issuer value, you get back a "controller document" that has verification relationships and associated verification methods. The kid must reference one of those verification methods under the appropriate verification relationship. This option would be in line with how things work with DIDs and how things work with Data Integrity.

[OR13]

@dlongley your suggestion is the best I have heard so far... but... can we do better?

[iherman]

The issue was discussed in a meeting on 2022-10-12

• no resolutions were taken

View the transcript

6.1. Dereferencing relative to issuer (issue vc-data-model#914)

See github issue vc-data-model#914.

Kristina Yasuda: the first one was #914 where Brent added the label 'discuss'.
… de-referencing relative to issuer.
… . Brent was asking the question.
… Orie or Brent -- any comments?.

Orie Steele: an issuer is a well-understood term at this point.
… you can use the term definition from VC spec 1.1.
… in the case of a Data Integrity proof, there's a well-defined relationship between the issuer, the verificationMethod, and the proof.
… so in a DI proof, as a developer, I know what to do with a key and how to verify.
… in the context of JWTs, it's completely un-defined.
… this may be shocking, you may ask -- how can I use JWTs if I don't know how to obtain the public key?.
… I'm confused as well. I've worked on some documents at DIF a while ago, to make it easier to understand how to obtain the key material, with a JWT VC.
… there's a few options we discussed, the most widely adopted is unfortunately my fault, it's to use a 'kid' value that is an absolute reference to the key material.
… that you use to verify the VC. The security risk there is -- if you're just de-referencing the material from kid, there's a chance that the kid and issuer don't agree.
… so, you can see here in that example, if we take the 'iss' and 'kid' together and use those, that might work, but it's different from what I've seen in the wild.
… which was - an absolute 'kid' vs relative url.

Michael Prorock: +1 orie.

Orie Steele: but basically, we need a consistent definition of how to obtain a public key for a JWT.

Kristina Yasuda: thanks Orie.

Manu Sporny: +1 to providing guidance.
… we should do that, since this has come up multiple times, and we keep making different decisions.
… the thing that stands out to me that feels dangerous, is the whole 'iss' + 'kid' approach.
… which presumes that the verification method is always relative (or can be relative).
… this is dangerous because it presumes that the 'iss' property always exists.
… but for Data Integrity proofs, they can be applied to non-VC objects.
… in use cases where there's no issuer.
… if 'kid' is always a relative URL and it's enforced, then that might be ok...
… I'll also note that there are valid concerns about putting absolute URLs everywhere.
… where the key that's signed is different from the issuer's URL.
… some people look at that as a feature, some as a bug.

Orie Steele: so, the example that I've shown, with 'iss' + proof verificationMethod was confusing.
… in a VC that uses a DI proof, you only need proof.verificationMethod to obtain the key material.

Manu Sporny: ok, thanks Orie, that's helpful..

Gabe Cohen: +1 Orie, ran into this exact issue this week when implementing resolving keys + verifying jwt-vcs.

Orie Steele: as far as I'm aware, you're not required to enforce that the key used to sign a VC is controlled by the issuer.
… I've seen libraries that check for this, and I've implemented that myself.

Dave Longley: +1 to Orie, thanks for clarifying.

Orie Steele: anyways, so this issue is -- how did you get to that key material in the first place.

Manu Sporny: ah, I think I see....

Orie Steele: the other point I don't agree with that Manu made.
… is that DI proofs apply to things that aren't VCs. I agree that that's true, but VCs /require/ issuers.
… so one is not going to encounter a situation, in the context of this WG, where that would happen, unless we make normative changes.

Markus Sabadello: I agree, it feels like this should be defined (wrt relative IDs).
… in the JSON-LD perspective, such a relative ID would be resolved relative to the 'id' field, rather than the 'issuer' field.

Gabe Cohen: I'm curious where the normative change needs to be. Is this something that the VC JWT spec can handle?.

Orie Steele: To be clear, I am NOT suggesting proof.verificationMethod be ANYTHING other than an absolute IRI to a verificationMethod.

Orie Steele: I am pointing out that people still have questions about relationship to issuer..

Manu Sporny: ok, so what Orie just said (in chat) -- great, I totally agree with that.
… so what's our further question....

Orie Steele: manu, we are talking about this: https://github.com/digitalbazaar/vc-js/blob/main/lib/CredentialIssuancePurpose.js#L72.

Manu Sporny: how about this -- let me try and state a question and provide an answer.
… do we want relative URLs associated with any kind of key material in DI proofs. and the answer is, absolutely not. We should have absolute URLs everywhere.
… does anyone object or disagree?.
… introducing relative URLs, especially around key material in DI proofs, is asking for trouble.
… since as Markus points out, there are ways to change the base URL.
… all that to say, for DI proofs, absolute IRIs are required any time there's key material. not sure what to do for JWTs.

Dave Longley: if we haven't done this already (in the DI spec, we were going to specify this).
… that the base URL for a VC must be null.
… which would enforce the usage of absolute URLs.

Steve McCown: +1 for absolute URLs in proofs, etc..

Dave Longley: what I wanted to ask about -- is what Orie asking specific to JWTs?.

Orie Steele: iss: did:example:123, kid: #key-1 .... is safer..

Kristina Yasuda: +1 to ack selfissued.

Michael Jones: this may be more of an analogy to think about,.
… rather than directly actionable, but - JWT key ids just tend to be locally unique IDs, not URLs.
… you get the key from a .well-known off of the issuer, or something along those lines.
… so I'm sympathetic to 'kid's being local to the context of key retrieval.
… I know that doesn't answer the question of where do you get the keys..

Orie Steele: yep... the DIF vc-jwt implementation made it up... because there was no guidance..

Orie Steele: which hurt us all..

Michael Jones: but I think that should be separate from requiring kid from being absolute URLs. That would be overkill.

Orie Steele: as many of you, I'm interested in compact representations, where we don't repeat information, and I'm also interested in building safe APIs.
… in the context of VCs -- I'm going to focus on JWTs and JOSE for a sec.
… there are some usages, in the JOSE spec, that are more or less safe.
… and we should discuss on whether we should allow both, or ONLY require safe usages.
… and Mike is right -- the definition for 'kid' is that it's an opaque hint, it's not a direct absolute IRI, it doesn't provide key resolution advice.
… if we were to say nothing (in the VC spec), in my opinion it would be very harmful, in using JOSE with JWT.
… because 'kid' is something a developer expects to be helpful.

Manu Sporny: +1 to "we should explain exactly how to use iss/kid in VC-JWT".

Orie Steele: we should explain why 'kid' is valuable and helpful, and how we should use it to get the key material.
… regarding the duplicate info piece, I propose that we should break the convention.
… that 'kid' should be an absolute URL, and I think that's a mistake now.
… so I would propose we use 'iss' + 'kid' together, instead.
… it's safer, and would allow us to have clearer guidance for implementers.

Michael Prorock: +1 to iss and kid.

Orie Steele: if we don't give that guidance, they could do multiple different things.
… but devs will for sure be doing extra work.
… so we should plan to make their lives easier by dictating one consistent way of how to obtain the key materials for a JWT.
… so while it's possible to leave optionality in, wrt key resolution, I don't think we should.

Kristina Yasuda: thanks, Orie.

Manu Sporny: +1 to removing optionality wrt. key resolution with respect to VC-JWT..

Kristina Yasuda: so, do we want to provide guidance on what to do with 'kid's in a JWT VC?.

Michael Jones: again, I'll make an analogy to other solutions.
… in OIDC4VC work, we do retrieve the keys based on the issuer.
… now, there is a case statement, which I think is ok,.
… if the URL of the issuer is a DID, you retrieve the DID keys. if the URL is an https:// url, you tack on a .well-known/ identifier, and get the keys from that place.
… and I think we'd do well in the VC 2.0 spec to do something similar.
… recognizing the different affordances with DIDs and HTTP URLs.
… but it would be good to have a normative retrieval method, yes.

Orie Steele: +1 to normative guidance on retrieving public keys..

Dave Longley: +1 for normatively described ways to get the keys.

Manu Sporny: real quick, +1 to what Mike was saying, and to what Orie was saying -- we should be super clear, eliminate optionality.
… and that's what people are suggesting, let's provide guidance for VC JWTs.
… my concern is that we may not be thinking --- iterating though every single scheme (did, http) might be difficult. But what about people who want to use other schemes, IPFS, etc?.
… that's challenging (the 'case' statement grows).
… presuming we might do a relative URL thing might also be problematic.
… this may not match every type of protocol scheme.
… the only way you could be sure, is by having an absolute URL in 'kid'.

Orie Steele: We can't comment on identifier formats that are not standards..

Dave Longley: Orie: well, we can comment on that -- we could say that how you fetch the keys depends on the identifier format and only these N are defined by the spec.

Manu Sporny: I think we're presuming a security issue.
… the only thing I can think of here is -- 'iss' is a totally different URL from the URL in 'kid'.
… like, if the issuer is a university, then the issuer URL would be the homepage.

Orie Steele: FWIW, I could live with kid MUST be absolute or kid MUST be relative to iss... I can't live with both..

Manu Sporny: but if the university is using an HSM to sign it, or a hosted key provider, then the 'kid' might be on a totally different domain.
… so that's my concern -- in the rush to provide clear guidance.
… (such as 'one of them is relative to the other one'), we'll eliminate valid use cases.
… to be clear, I think absolute IRIs are the thing to do, but I'm interested in people who disagree.

Markus Sabadello: +1 to absolute IRIs.

Orie Steele: concretely, the security issue is -- I create a JWS signature tomorrow, and I have 'iss' that's one value, and the 'kid' is a DID key URL,.
… then it will always resolve, and there's no way to revoke it.
… so the VC will always verify.
… and to protect against that, we'd need to add additional text, such as 'hey, make sure this key is controlled by the issuer'.

Dave Longley: there needs to be a trusted link between the issuer and the key..

Manu Sporny: ^^ yes, that..

Orie Steele: and we'd need to have a per-protocol discussion for the relationship between iss and kid.
… the comment about that we don't know the various identifier schemes, I don't think that matters --.
… we can define the schemes we expect to see in the wild. if somebody can make a case for another type of identifier, let them come forth.

Michael Jones: +1 to defining key retrieval methods for the URL types that we do expect to be used.

Orie Steele: we shouldn't wait, to provide clear guidance.

David Waite: the reason 'kid' is defined as a hint, is because you need to know, for a given kid, is that it's something an issuer vouches for.
… DIDs provide a way to enforce this.
… for OIDC4VC, we provided a different mechanism.

Orie Steele: dwaite is giving a good argument for why kid and iss should be used together IMO... it would be safer to use relative..

Orie Steele: +1 dwaite.

David Waite: the issue with having absolute URIs -- we still have to define how does somebody enforce / check that the issuer controls the kid?.

Dave Longley: Orie: it being "relative" is just a shortcut to getting a trusted link / attestation from the issuer that the key is, in fact, theirs and intended to be used to sign a VC..

David Waite: so, they can be relative, maybe the 'kid' is not a URI but a fragment, but there still has to be a way.
… of how to go from an issuer to the key, or if the key is trusted by the issuer.

Manu Sporny: here's how this is solved Data Integrity -- you HAVE to ensure there's a bi-directional link between issuer and key.
… so, you go to the controller document (such as the DID doc), and you verify that the key is authorize3d.
… clearly we need to have further discussion, but I'm confident we can unify the guidance.

Kristina Yasuda: thank you, everyone. Orie, anything we can do in this issue, to clarify?.

Orie Steele: comment on the issue, make concrete proposals we might discuss on the follow-up call.
… we need more engagement on issues.

Kristina Yasuda: agreed.
… we encourage everyone to make proposals, add comments to the issue, so we can make progress.

---

[msporny]

We have to specify how this works in the vc-data-integrity spec. I'll link to that PR when we have it... should be in the next couple of weeks, hopefully.

[iherman]

The issue was discussed in a meeting on 2023-01-11

• no resolutions were taken

View the transcript

3.1. Dereferencing relative to issuer (issue vc-data-model#914)

See github issue vc-data-model#914.

Brent Zundel: Start with issue 914..
… Referencing relative issuer. When somebody looks at the issuer URL, what should they get back?.
… No action taken since last time. Any updates?.

Manu Sporny: There will be text in the VC Data Model who to reference this..
… We can keep it like this if it addresses Orie's concern..
… This text has to be written for the VC Data Integrity Model..

Brent Zundel: When this PR has been written, it should be linked to the issue..
… Next issue is 846..

[iherman]

The issue was discussed in a meeting on 2023-02-14

• no resolutions were taken

View the transcript

4. Extension Points.

Brent Zundel: look at these things that need to be fixed.
… we need to fix dereferencing.
… first question, where are these terms defined.
… second question, look at these extension points.
… all these are non normative.
… and we don't even point to a single way to use them.

Paul Dietrich: URL?? Did this change in 2.0? In 1.1 I though they were URI?.

Brent Zundel: we need to point to something.

Dave Longley: Paul_Dietrich_GS1: URL is the same thing as URI in the new world..

Brent Zundel: the reason for this, is because... we have been dinged on our charter for this stuff.
… its considered to be not a good thing, what we have done..
… we feel we can do better.
… what should we do about these things?.
… should we remove these things... since we have nothing to point to.

Kristina Yasuda: for refresh: issues 981, 1020.

Kristina Yasuda: for terms of use: issue 1010.

Orie Steele: illuminates us with the wisdom of having 10k registries.... then ends snark and procedes to suggest that unless we can define one normative type for each item on this list that they should be dropped.

Kristina Yasuda: issue 991 says it is about status, but not really...

Kaliya Young: +1 orie!.

Orie Steele: removing them from the doc does not mean they aren't useful or fine, just that they don't belong in the spec.
… let's avoid FOs, let's do a better job.
… let's get things polished, then add.

Dmitri Zagidulin: @Orie - do you think we can thread the needle by just having a list of 'reserved terms' in the main VC WG spec?.

Manu Sporny: there is also a render extension.
… we have one for status.
… we could point to the CCG for some of these.
… for refresh for example.
… as far as dereferencing, it depends on the type.

Dmitri Zagidulin: as in, would 'reserved terms' without definition raise objections?.

Manu Sporny: in many cases, its just a URL.
… sometimes its a URL to another file type.
… not sure what we can do, to fix this.
… they can be ANY url.

Brent Zundel: Can we say more than, it is just a URL.
… we need to define it a bit more.

Manu Sporny: what about a human readable web page?.

Brent Zundel: we need at least 1 way to do things.
… we don't need more than 1.
… people need to be able to read the spec to understand how to use these extension points.

Dave Longley: we should also say, these id's depending on where they occur, they don't need to derefernence to things.
… we should explain when urn:uuid is more appropriate.

Michael Prorock: +1 uuid - that is often a desired behavior.

Dave Longley: we should describe what a holder dererefernces too, it should go to a controller document, like issuer.

Dave Longley: "id": "urn:uuid:<uuid>.

Michael Prorock: +1 to uuid, maybe we cover URN in URL examples as well.
… sometimes we like to define schemas in vocabularies.
… sometimes we over URLs, hashes, etc....
… no blockchain required.
… md5 is till observed in the wild... maybe hashes should be documented?.

Dave Longley: digestMultibase :).

Michael Prorock: should be integrity protect schemas, how?.

Dmitri Zagidulin: +1 to using digestMultibase (which includes hash and content type).

Michael Prorock: we should describe what we are seeing in the wild.

Gabe Cohen: we have one in the CCG.
… there is one in the CCG, I would like to move it into this working group, similar to status list.
… so it can stay in the spec.

Joe Andrieu: I am in favor of removing things that are not defined....
… we can use CCG for optional fields.
… we need to remove SHOULD from some of these.

Samuel Smith: I want to revise my proposal for the assurance method. My cognative dissonance was with the term confirmation method which lumped together multiple things. But now that we are using the term "assurance" then the dissonance resolves is we use the NIST terminology precisely which separates Authenticator Assurance Level from Identity Assurance Level. Authenticator Assurance is largely cryptographic whereas as Identity Assurance is not..

Joe Andrieu: URLs being here is because of WHATWG... confusion.
… maybe we need to change the guidance on this.

Kristina Yasuda: the property part... status we have a work item.
… credential schema, at risk..
… refresh service, I am against including it.
… termsOfUse, no strong opinions, it seems at risk.
… evidence, lots of issues, ccg item exists, but regarding brents original point, we can't spend time on all of this.
… render, seems useful, but maybe we don't need it just yet.
… render seems at risk.
… chair hat off for comments.

David Chadwick: Not sure we need to point to standards.
… we don't have any standard terms of use, but we are pointing it at trust infrastructure.
… its using EIDAS trust lists.

Samuel Smith: So AA should be an external to the VC data model because it is narrowly defined to be the authentication of the presenter whereas IA should in the data model per subject. So the revised pull request is that we have three constructs. Identity assurance evidence of the Issuers assurance, Issuer recommended methods of identity assurance for the velidator, and issuer recommend methods of authenticator assurance for the validator..

David Chadwick: does it have to be a standard? seems like the bar is too high.

Dmitri Zagidulin: concrete proposal, we remove these sections from the spec, but then reserve the terms.
… so that we can have seperate specs for each one.

Brent Zundel: our charter does say, for all normative required properties....

David Chadwick: @dmitriz very interesting comment!.

Brent Zundel: we acknowledged there is a problem here, but it does not mean that we should aim for the low bar we set..

Dmitri Zagidulin: @dlongley - what if we phrase it 'Reserved for future use'? :).

Brent Zundel: lets consider why we are keeping things we can't provide references for.
… agree with dimitry.

Dave Longley: dmitriz: i'd be worried that DavidC's usage would be invalidated by that language.

Dmitri Zagidulin: @dlongley - remind, what usage is that?.

Orie Steele: notes variations on VC JSON Schema and other ways of linking json schema to credentials and formats.

Dave Longley: dmitriz: he just mentioned he's using termsOfUse with EIDAS.

Orie Steele: maybe we don't have to point this to a normative standard.
… however at ietf dowrefs are disouraged.
… for good reason to that people are only being directed to stuff that is "real".

Ted Thibodeau Jr.: W3C allows pointers to specs-in-progress, there just has to be a static, permanent document.

Dmitri Zagidulin: @dlongley - he's 'future use'! :).

Orie Steele: 100% agreement to remove all this stuff.

Ted Thibodeau Jr.: those pointers can't be normative, however.

Orie Steele: +1 dimitriz.

Brent Zundel: I understand we have the same notion regardingn Downref.

Michael Jones: its a bit of a tangent, on WHATWG.
… the names are meaningful, and we should maybe not have... since its not great.

Phillip Long: +1 dmitriz practical suggestion re: reserved usage.

Joe Andrieu: I am a big fan of removing first, and adding good stuff that meets our bar back.

Dave Longley: +1 to Joe, reserving the terms eliminates the ability to experiment.

Joe Andrieu: I am opposed to "reserved terms", because it would prevent people from experimenting.

Brent Zundel: so far quite a few folks in favor of removing terms.

Michael Prorock: thank you joe for the reserved comment.

Joe Andrieu: the question I have is regarding termsOfService.
… is that VC and VP?.

Dmitri Zagidulin: if 'termsOfService' is only in VCs, Phil and I will be adding a proposal to adding 'termsOfUse' to VPs.

Joe Andrieu: doc searl is working on something related to that... maybe its an option.

Manu Sporny: the objectors, we spoke to them... they wanted proof there is interop on these things.
… that is a much lower bar than REC or defintion.

Joe Andrieu: doc searls' work is over at https://sagroups.ieee.org/7012/.

Manu Sporny: we can just point to CCG things.

Joe Andrieu: (user generated terms of service).

Manu Sporny: I think I am -1 to removing things pre-maturely.
… some things seems safe to remove, other seem like we should not remove.
… credential refresh is deployed, we don't want to remove that....

Kristina Yasuda: it's in v1.1.

Manu Sporny: we would just violate the spec, if we remove things we use in production.

Kristina Yasuda: nooooooo.
render is not simple at all.
we have a variation of "render" deployed too.

Manu Sporny: render is simple enough... we should be able to do that in CR.
… lets talk about it, maybe this will work..

Kristina Yasuda: but it is not simple and it is not only about svg as in PR.

Dmitri Zagidulin: @kristina - render /is/ simple as an extension point..

Manu Sporny: status list keep, credential schema lets point to the ccg, refresh service has an implementation and people using it, evidence is ok, termsOfUse seems poorly supported currently.

Kristina Yasuda: for render, at least just point to a spec in DIF, no reinventig please.

Manu Sporny: is anyone using termsOfUse?.

David Chadwick: We used it in tests.
… it communicates trust framework.
… if you demonstrated interop, then it stays.

Dmitri Zagidulin: @kristina - that is what the paper proposes, fwiw. https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/rendering-vcs-snapshot-9-27-22.md (using existing specs like DIF).

Kristina Yasuda: refresh has been causing a lot of confusion.

Brent Zundel: If there is something on this list, that you are using, will you raise a PR to modify the spec to point to something?.

Ted Thibodeau Jr.: link to "this list"?.

Oliver Terbu: there is a number of ppl that use credentialSchema with JSON schemas.

Brent Zundel: slide 72.

Ted Thibodeau Jr.: tnx.

Dmitri Zagidulin: +1 oliver -- Open Badges v3 uses credentialSchema w/ json schema.

Brent Zundel: we need to concretly move forward.
… seems people want to do things, but will they open PRs?.

Kristina Yasuda: list of issues with ready for PR: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3A%22ready+for+PR%22.

Michael Prorock: The danger of reserved, sounds great, but ... maybe its not a good solution.

Phillip Long: +1 Oliver, so does CLRv2 from 1EdTech and they have for both OBv3 and CLRv2 at least four commercial vendors committed to implement it..

Michael Prorock: it seems reasonable to clarify language on URLs.
… I will maybe open a PR.
… implied by the core of what we do is status, the other items, maybe we should drop the rest.
… they can be used.
… they don't need to be pointed to CCG docs.
… CCG is awesome place to incubate, but it doesn't seem like a good place to point to... for the single reference for TRs.
… anywhere we are considering to pointing to the CCG, seems dangerous to the work....
… we can recharter to cover items, lets not use the CCG to cover overflow.

David Chadwick: I covered termOfUse.

Paul Dietrich: was there any conclusion on dereference URLs vs non dereference?.

Dave Longley: -1 to creating an artificial problem here -- people are using things and if that rises to the level of interop needed by previous objectors, we should not remove things and create chaos/trouble..

Dave Longley: we have enough other real issues to address..

Brent Zundel: We seem to want to clarify URL vs URN as legal for use cases.

Dmitri Zagidulin: what if we define 'VC Extension Mechanism' once, in a section, since we're using the exact same mechanism anyway. and then list terms that fall under that..

Michael Prorock: we can cover cases for both URL and URN, DID etc....
… we can provide better language.

See github issue vc-data-model#914.

Andres Uribe: @dmitriz I believe that's already defined in https://www.w3.org/TR/vc-data-model/#extensibility.

Joe Andrieu: We should back away from WHATWG.
… it breaks file URLs.

Dmitri Zagidulin: @andres - oh right!.

Joe Andrieu: so seems like we should not follow that guidance.

Kristina Yasuda: also a bit related: #709.

Joe Andrieu: question for Manu, no snark implied.

Kristina Yasuda: and this kind of #945.

Joe Andrieu: my understanding is that your current VCs won't break anything, because you already cover this use case under 1.1.

Dave Longley: https://url.spec.whatwg.org/#example-url-parsing <-- some examples of valid file URLs are in there.

Manu Sporny: Do we want to open that can of worms.
… it is true that 1.1 context, will perserve terms that are dropped.
… some folks won't be insulated from breaking changes.

Dave Longley: -1 that v1.1 will be affected, the JSON schema would still check the literal context values.

Manu Sporny: why are we trying to do work that was not asked for by objectors.

Joe Andrieu: because it's not about formal objections.

Gabe Cohen: PR to add a schema reference #1042.

Manu Sporny: the reason we added extension points, was to allow people to use them.

Michael Prorock: we don't have requirements for this.

David Chadwick: +1.

Manu Sporny: we don't need to describe anything, just let people use the extension points.

Dave Longley: +1 to Manu ... stop messing with people that are doing useful things :).

David Chadwick: we are actively using ToU.

Manu Sporny: concern is that we are solving a non problem.

Orie Steele: Lets try to raise some PRs.

---

[OR13]

data integrity did a good job on this: https://w3c.github.io/vc-data-integrity/#retrieve-verification-method

I suggest we close this, and note that we do not intend to address this in the core data model.

[Sakurann]

agreed that this topic should be addressed in the securing specs (vc-jwt and data integrity)

[iherman]

The issue was discussed in a meeting on 2023-04-11

• no resolutions were taken

View the transcript

1.6. (issue vc-data-model#914)

See github issue vc-data-model#914.

Kristina Yasuda: "Dereferencing relative to issuer" - We should add guidance somewhere regarding dereferencing relative to an issuer..

Orie Steele: believes Data Integrity has solved for this and that VC-JWT has not.

Orie Steele: For the record, this is resolved for data integrity.

Orie Steele: https://w3c.github.io/vc-data-integrity/#retrieve-verification-method.

Orie Steele: this is a fundamental issue - data integrity defining this in DI spec implies this issue should be closed in favor of solving in VC-JWT.

Dave Longley: +1 to brent.

Brent Zundel: feels like this is open elsewhere and should be closed here.

Kristina Yasuda: good. closed..

[iherman]

The issue was discussed in a meeting on 2023-04-11

• no resolutions were taken

View the transcript

1.6. (issue vc-data-model#914)

See github issue vc-data-model#914.

Kristina Yasuda: "Dereferencing relative to issuer" - We should add guidance somewhere regarding dereferencing relative to an issuer..

Orie Steele: believes Data Integrity has solved for this and that VC-JWT has not.

Orie Steele: For the record, this is resolved for data integrity.

Orie Steele: https://w3c.github.io/vc-data-integrity/#retrieve-verification-method.

Orie Steele: this is a fundamental issue - data integrity defining this in DI spec implies this issue should be closed in favor of solving in VC-JWT.

Dave Longley: +1 to brent.

Brent Zundel: feels like this is open elsewhere and should be closed here.

Kristina Yasuda: good. closed..