Open AdamJLemmon opened 3 years ago
@AdamJLemmon thanks for raising this.
From a data modeling perspective each top level json object should have an @context
and should be valid JSON-LD.
If you want to store an object and its metadata inside a single JSON object, the resulting "type" will not be a valid verifiable credential, however it can still be valid JSON-LD.
for example:
{
"@context": ["https://w3id.org/wallet/v1"],
"id": "urn:uuid:123...",
"type": "MyFancyCredentialWithMetaData",
"format": "w3cvc-jwt",
"credential": eyJhVCJ9Jzd..MDsw5c,
"authorizations": [{
"type": "frozen-refresh",
"httpUri" "https://issuer.example.com/credential",
"httpMethod" "POST",
"token": {
"access_token": eyJhbGciOiJIUzI1NiIsInR5c...Qssw5c,
"token_type": "DPoP",
"expires_in": 2677,
"expiry": 1562262616
}]
}
Then we would expect this spec (https://w3id.org/wallet/v1) to define "MyFancyCredentialWithMetaData", and other properties, valid JSON-LD provides definitions for terms, you can't just add object members with defining what they mean.
It looks like what you are really trying to do is define a credential with metadata type, that can wrap a credential and store additional properties, each of those additional properties needs to be clearly defined...
For example, where is "w3cvc-jwt" defined? Where is "frozen-refresh"?
The simplest path forward would be to give your top level object a name, and add examples to the spec of how it should look... keeping in mind that the examples must be valid JSON-LD to be accepted.
Perhaps we can create a type "CredentialWithMetaData2021" as a placeholder for you?
I think this can be viewed as a special case of #36. See proposal in PR #63 -- if that satisfies this use case, I'd propose a subsequent PR calling out this example.
(So beyond extensibility for non-standard data, this allows extensibility for ALL data, which I'd briefly thought about and forgotten.)
For example, where is "w3cvc-jwt" defined? Where is "frozen-refresh"?
I'm late to the party, but "w3cvc-jwt" is referenced here: https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
I have no earthly idea what frozen-refresh is. Searches return a kind of shampoo that sounds divine but is probably not relevant to this discussion. But feel free to go buy yourself some Mint Frozen Refresh Citrus & Herb Shampoo
@OR13 - in your https://github.com/w3c-ccg/universal-wallet-interop-spec/issues/48#issuecomment-762406878 above --
Then we would expect this spec (https://w3id.org/wallet/v1) to define "MyFancyCredentialWithMetaData", and other properties, valid JSON-LD provides definitions for terms, you can't just add object members with defining what they mean.
Typo in the last phrase radically changes meaning -- with defining
should be without defining
.
Hi All, I scanned the issues for related and didn't seem to notice anything exact but apologies if this is redundant.
Essentially we need to store metadata about credentials within the wallet for later use. This primarily relates to information about the relationship with the issuer of the credential to perhaps be able to "refresh" it at a later date, have it issued to a new unique pairwise DID, etc but also information to describe the credential itself. For example storing the
format
directly inline with thecredential
. Of note we are beginning to suggest aformat
be returned in some of the OIDC credential issuance flows as well.I have noticed both the
Metadata
andConnection
sections which could potentially be used with correlation to map to the credential I suppose but am curious if perhaps we could enrich theCredential
data model itself. Or maybe I am missing another way to include such? Some examples below. I did come across #6 and the note of storing authorizations in the spec which feels relevant. Look forward to others' thoughts, thanks!W3C VC JSON-LD:
W3C VC JWT:
W3C VC JSON-LD with Authorizations:
permissions
,access
, how to render or visualize .. etc