EC-SEAL / vc-issuer

SSI Verifiable Credential Issuer for SEAL service

0 stars 0 forks source link

issue: Structure of VC #1

Open endimion opened 4 years ago

endimion commented 4 years ago

Issue report

VC transfer JSON-LD, JWT message: { "iat": 1584959383, "exp": 1587551383, "sub": "did:ethr:0xbbcac37441c101cf126dc46c427d6993e0d7db7f", "claim": { "SEAL-EIDAS": { "eidas": { "given_name": "ΧΡΙΣΤΙΝΑ, CHRISTINA", "family_name": "ΠΑΛΙΟΚΩΣΤΑ, PALIOKOSTA", "source": "eidas" } } }, "vc": [ "/ipfs/QmNbicKYQKCsc7GMXSSJMpvJSYgeQ9K2tH15EnbxTydxfQ" ], "iss": "did:ethr:0xd502a2c71e8c90e82500a70683f75de38d57dd9f" }

Actual, VC structure: "SEAL-EIDAS": { "eidas": { "given_name": "ΧΡΙΣΤΙΝΑ, CHRISTINA", "family_name": "ΠΑΛΙΟΚΩΣΤΑ, PALIOKOSTA", "source": "eidas" } }

ross-little commented 4 years ago

I know this issue is on general structure so perhaps we should also have a description in wiki updated with the actual VCs SEAL will support (i.e. 1) specific identity source VCs from eIDAS , eduGAIN , eMRTD etc. 2) HEI SP specific VCs as needed by HEI services 3) a la carte VCs) with the name of individual micro claims specified there. From what I cansee there is no current refernce specification of eIDAS MDS specified as verifiable claims for example you use "family_name" rather than the eIDAS friendly name: “FamilyName“. So if this is not existing it is good that we make our proposal public on the wiki.

endimion commented 4 years ago

Sure, however we could use the official (firendly) names of the attributes. That actually makes more sense. So ok I will add a page on the wiki that we can edit accordingly and narrow down on the specifics of each VC we will issue

cbuendia-atos commented 4 years ago

Hello Nikos, questions to understand the context:

What's the context of the JSON-LD? What does it represent? I guess u-port follows w3c recommendation, but I'm not able to find its different parts?
On VC field:"/ipfs/QmNbicKYQKCsc7GMXSSJMpvJSYgeQ9K2tH15EnbxTydxfQ": Are we using IPFS? What are we storing there?

endimion commented 4 years ago

Hi Carlos,

uPort uses jwt so the semantics on the json derive from there, I guess the semantics for claim, vc are defined in the JSON-LD but since I am not seeing the @context, and @id tags I am not sure atm. However, since we are using the uPort sdk we have to work with what we are given. We could I guess add a json-ld definition for the actual claims we generate if you guys think this would be benificial
In IPFS you store the metadata of the issuer, name, logo etc. This is not required you could have these as an second jwt inside the original (that's what the ipfs pin points to). However, then the QR codes generated become too big. So my vote is to just maintain an ipfs node on one vm (we can do that no problem) and pin the issuer metadata there..