- From: Orie Steele <orie@transmute.industries>
- Date: Thu, 17 Feb 2022 11:30:00 -0600
- To: David Chadwick <d.w.chadwick@verifiablecredentials.info>
- Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CAN8C-_+0r1F_15x+y9bq_g+UMR9SUkyaGcP3ZoC_AuME=nZR-g@mail.gmail.com>
> Duplication means that you would simply throw away the JWT timestamps
when creating the credential for storage.
The solution I proposed would perverse the JWT byte for byte.
The recoveredCredential would conform to the normative requirements of the
spec (XML Date Time), but if you encountered a problem with any property
you would have all the information you need to diagnose... If the issuer
chose JWT, I don't think there would be any problems since unix timestamp
to xml date time is NOT lossy... the other direction is potentially a
problem, but if we assume only JWT VC we don't have that problem...
The primary value of taking the "in addition to path" is the ability to
have vc.issuer be an object and not just a flat string... this is useful
when you want to include contact information or other fields, for example
see this Mill Test Report Certificate:
https://w3id.org/traceability#MillTestReportCertificate
If we choose the "instead of path", we lose all this information:
"issuer": {
"id": "did:key:z6MktHQo3fRRohk44dsbE76CuiTpBmyMWq2VVjvV6aBSeE3U", //
only field that is preserved.
"type": "Organization",
"name": "Bartell Inc",
"description": "Realigned maximized alliance",
"address": {
"type": "PostalAddress",
"streetAddress": "713 Funk Parkway",
"addressLocality": "Dannyside",
"addressRegion": "Alabama",
"postalCode": "17321",
"addressCountry": "Peru"
},
"email": "Dion_Stoltenberg@example.org",
"phoneNumber": "555-987-1014",
"faxNumber": "555-377-8843"
},
If we choose the "in addition to path", we keep all the information, but
the JWT `iss` in the payload is the authoritative issuer, not the `
payload.vc.issuer.id` field.
Off the shelf JWT libraries will happily handle the JSON in
payload.vc.issuer (really all of payload.vc) as they would any other JSON.
There is no technical solution for issuers that hand you bad credentials
(ones with contradicting claims) other than shaming them and refusing to
use their services.
They control the inputs and the outputs.
I would like the ability to do JSON queries over rich issuer fields, for
example:
Find me all credentials issued by X with email Y... can't do that if the
issuer field is dropped... or forced to be a string.
You can do it, if you preserve all fields except issuer.id.. but then your
conversion rules for "decodeAndRestructure" get a bit more complicated
(still manageable imo).
Looking forward to fixing this in VCDM 2.0.
OS
On Thu, Feb 17, 2022 at 11:15 AM David Chadwick <
d.w.chadwick@verifiablecredentials.info> wrote:
> On 17/02/2022 17:01, Orie Steele wrote:
>
> Thanks for the reply!
>
> So you're suggesting something like this:
>
> originalVerifiableCredential = JWT as String
> recoveredCredential = decodeAndRestructure(JWT) as JSON
> db.save({ originalVerifiableCredential, recoveredCredential })
>
> Yes something like this (only in our approach I stuck a proof property
> into the credential and put the JWT in there. Non-standard I know, but its
> only our internal representation of a JWT proofed credential. (I did argue
> for JWT proof types to be added to the VC data model v1, but this was not
> accepted).
>
>
>
> The problem with this approach is the ambiguity regarding the shape of
> "recoveredCredential"..
>
> Yes I know we discussed this regarding properties that don't fully
> transpose such as the timestamps. Your solution was to duplicate the
> properties rather than replace them. Duplication means that you would
> simply throw away the JWT timestamps when creating the credential for
> storage. Then you would remove any ambiguity. (Of course if you were
> getting a JWT VC from an issuer who is not using your software then this
> would not work if they were using replace rather than duplication.
> Hopefully we can fix this in v2.0)
>
>
> . but I agree that if that ambiguity were removed via VCDM 2.0 spec text,
> this would probably be optimal... because it would allow you to query
> credential claims regardless of proof format, from a common JSON structure.
>
> Exactly. This is my ultimate objective.
>
>
>
> I suppose I could implement this even on top of v1.1... do you think
> that's the best approach for now?
>
> In my opinion yes.
>
> Kind regards
>
> David
>
>
> OS
>
> ᐧ
>
> On Thu, Feb 17, 2022 at 10:34 AM David Chadwick <
> d.w.chadwick@verifiablecredentials.info> wrote:
>
>> Hi Orie
>>
>> as you know we spent quite some time on the text in the VC Data Model
>> v1.1 to differentiate between a credential and a verifiable credential, and
>> to highlight that regardless of the proof format (JWT, LD-Proof etc) the
>> credential is always the same once the proof has been removed.
>>
>> Therefore the obvious way to me to store any type of VC in a wallet is to
>> store the credential as JSON, along with the proofed VC, then the same
>> wallet will be able to receive any type of proofed VC and store the
>> embedded credential in the same way. I have also been highlighting this
>> model in the DIF PE group, so that the same Presentation Definition can be
>> used by any wallet to select any type of credential, regardless of the
>> proof type.
>>
>> Kind regards
>> David
>>
>>
>> On 17/02/2022 15:40, Marty Reed wrote:
>>
>>
>> > Decode and extract each assertion in a multi-assertion JWT individually
>> in the DB to handle queries and UI presentations.
>>
>> This seems potentially very use case specific, and like your database
>> will have to "know the shape" of all the credentials in wallets... I can
>> see this leading to really beautiful UX, but challenging to maintain when
>> new credential formats arise.
>>
>> >> We’re using the IMS Global OpenBadges and CLR standards for the JSON
>> assertions so the interpretations can be consistent. Currently these
>> standards are moving to a more directly VC compliant data model.
>>
>> I am hoping for a solution that provides ok ux for
>> arbitrary credential shapes... with minimal json transformation, and then
>> leaving room for your approach at a higher level... something like:
>>
>> credentials: [ { encoded, decoded }, { encoded, decoded }, ... ]
>>
>> Where a query can be run over decoded that can power your app specific ui
>> / ux considerations.
>>
>> I am concerned that there might be a lot of variability in the "decoded"
>> representation that would be harmful for interop... if we don't use a
>> standard form for the decoded representation. It sounds like you don't have
>> a standard form for it.
>>
>> > Store the encoded version in a data lake for transmission to other
>> platforms or consumers.
>>
>> This seems to confirm my thoughts regarding the encoded version... it
>> probably needs to be preserved exactly as it was received, along with some
>> metadata.
>>
>> >> We preserve the original authoritative issuer in this way but curious
>> as to other approaches.
>>
>>
>> -M
>>
>> ᐧ
>>
>>
>> Marty Reed | Chief Executive Officer
>> RANDA Solutions | 2555 Meridian Blvd | Suite 300 | Franklin, TN 37067
>> office 615 467 6387 | direct 615 915 5446 | fax 615 613 0517
>>
>> On Thu, Feb 17, 2022 at 8:28 AM Marty Reed <Marty.Reed@randasolutions.com>
>> wrote:
>>
>> In our open source project, we:
>>
>>
>>
>> 1. Decode and extract each assertion in a multi-assertion JWT
>> individually in the DB to handle queries and UI presentations.
>> 2. Store the encoded version in a data lake for transmission to other
>> platforms or consumers.
>>
>>
>>
>> https://opensource.ieee.org/ilr/ocp
>>
>>
>>
>> Best,
>>
>> Marty
>>
>>
>>
>>
>>
>> *Marty Reed** | Chief Executive Officer *
>>
>> *RANDA Solutions *| 2555 Meridian Blvd | Suite 300 | Franklin, TN 37067
>>
>> *office* 615 467 6387 | *direct* 615 915 5446 | *fax* 615 613 0517
>>
>> *Confidentiality Disclaimer:* This email and any attached files are
>> confidential and intended solely for the use of the individual or entity to
>> which it is addressed. If you are not the person or entity to whom this is
>> addressed, or the person responsible for delivery of this email to the
>> intended recipient, you have received this email in error. Any use,
>> dissemination, distribution, forwarding, printing or copying of this email
>> including attachments is strictly prohibited. If you received this email in
>> error, immediately delete it from your system without copying and notify
>> the sender so that our records can be corrected.
>>
>> *From:* Orie Steele <orie@transmute.industries>
>> *Sent:* Thursday, February 17, 2022 8:21 AM
>> *To:* W3C Credentials CG (Public List) <public-credentials@w3.org>; Mike
>> Jones <Michael.Jones@microsoft.com>; David Waite <dwaite@pingidentity.com
>> >
>> *Subject:* Recommendations for Storing VC-JWT
>>
>>
>>
>> Hey Folks,
>>
>> As you know JWT compact representations are base64url encoded, making
>> them impossible to query over from a database like Cosmos, Neo4j, MongoDB
>> etc.
>>
>> A natural solution is to store the JWT in flattened form, like this:
>> https://www.rfc-editor.org/rfc/rfc7515#section-7.2.2
>>
>> However, it's not clear to me from the RFC what these actually look
>> like... this is what I want:
>>
>> {
>> "header": {
>> "alg": "EdDSA",
>> "kid":
>> "did:key:z6MkneEzjgD4Rerd14F62MmcKXY5LQsLQeY6UntTQmtSKwFh#z6MkneEzjgD4Rerd14F62MmcKXY5LQsLQeY6UntTQmtSKwFh"
>> },
>> "payload": {
>> "iss": "did:key:z6MkneEzjgD4Rerd14F62MmcKXY5LQsLQeY6UntTQmtSKwFh",
>> "sub": "did:example:123",
>> "vc": {
>> "@context": [
>> "https://www.w3.org/2018/credentials/v1",
>> "https://w3id.org/security/suites/jws-2020/v1"
>> ],
>> "id": "urn:uuid:494",
>> "type": ["VerifiableCredential"],
>> "issuer":
>> "did:key:z6MkneEzjgD4Rerd14F62MmcKXY5LQsLQeY6UntTQmtSKwFh",
>> "issuanceDate": "2010-01-01T19:23:24Z",
>> "credentialSubject": { "id": "did:example:123" }
>> },
>> "jti": "urn:uuid:494",
>> "nbf": 1262373804
>> },
>> "signature":
>> "pRMwWUl1rjVpUIChduHosy2NeZfdeBo0jkWfLKVXfmVO8Q31PN3kcw0CGIG78hS0z9MdXnOV7L3mBQtKBslQDA"
>> }
>>
>> If I can't represent a VC-JWT as JSON in a database, then I can't query
>> over its contents, which is important for many public credential use cases.
>>
>> It would seem the rational thing to do is:
>>
>> 1. to store them decoded
>> 2. store a decoded version next to the encoded version.
>>
>> I would still avoid transmitting them decoded since JSON member order
>> might not be preserved, and reordering would break signatures.
>>
>> My question are:
>>
>> 1. What is the name for the representation I gave above in JSON (is this
>> what flattened looks like), or is there a better way?
>> 2. Which of the 2 storage options should JWT developers take, when
>> planning to query over JWT verifiable credentials?
>>
>> Regards,
>>
>> OS
>>
>> --
>>
>> *ORIE STEELE*
>>
>> Chief Technical Officer
>>
>> www.transmute.industries
>>
>>
>>
>> <https://www.transmute.industries/>
>>
>> ᐧ
>>
>>
>>
>>
>> --
>>
>> *ORIE STEELE*
>>
>> Chief Technical Officer
>>
>> www.transmute.industries
>>
>>
>>
>> <https://www.transmute.industries/>
>>
>>
>>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>
>
>
--
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries
<https://www.transmute.industries>
ᐧ
Received on Thursday, 17 February 2022 17:30:27 UTC