trustbloc / context Goto Github PK

The basic version was added as part of #31. This needs to be updated to match some standards.

https://w3c.github.io/vc-imp-guide/#referencing-credentials-without-integrity-protection

age_over_NN - Age attestation: Nearest “true” attestation above request

Need to define the exact attribute names (replace NN) in the context.

Ref - #39

Remove https://github.com/trustbloc/context/blob/master/vc/examples/driving-license-v1.jsonld once edge-sandbox is updated to use mDL type - trustbloc/sandbox#473.

biometric_template_xx - Biometric template XX

Need to define the exact attribute names (replace XX) in the context.

Ref - #39

https://w3c.github.io/vc-imp-guide/#referencing-other-credentials

Use Case - Drivers License credential with evidence in a separate assurance credential

online_token _xxxx - Online token

Need to define the exact attribute names (replace xxxx) in the context.

Ref - #39

trustbloc/adapter#188

Does the subject have to be a DID?

This field is supposed to hold an identifier - nothing more.

• It doesn't need service endpoints because none of the parties involved will be communicating with this identifier.
• Creating keys for each of these new identifiers adds extra burden on their creator

I suggest we rename this to "subject" and remove any constraints on it being a DID.

Remove once trustbloc/adapter#188 is implemented

The AuthorizationCredential model does not indicate the resources their owner has authorized access to. This makes it impossible for the requesting party to determine which authz cred to use for each location when multiple remote credentials are to be retrieved.

The resources granted access in an authz credential are its scope - I propose this new attribute is called exactly that, scope. Further, since a single resource location may serve multiple scopes, scope should be an array.

Since we don't want to invent new scope language, we should reuse the presentation-exchange input descriptors. So, scope should be an array of input descriptor objects.

{
    "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://trustbloc.github.io/context/vc/authorization-credential-v1.jsonld"
    ],
    "type": [
        "VerifiableCredential",
        "AuthorizationCredential"
    ],
    "id": "urn:uuid:73f5b76a-d616-4e16-81ad-216cf9632394",
    "issuanceDate": "2020-08-14T20:00:06.033356825Z",
    "issuer": "urn:uuid:fb80ed43-18b0-47e1-8f70-7020164c3302",
    "credentialSubject": {
        "id": "urn:uuid:65576427-01e4-4304-957b-ce11a1a6f4e2",
        "scope": [
            {
                "schema": {
                    "uri": "https://trustbloc.github.io/context/vc/examples/credit-card-v1.jsonld"
                },
                "constraints": {}
            }
        ],
        "subjectDID": "did:peer:1zQmVYMa5Q46sL4MsYuAd5sLEkjHoxa3ajfjUArBoXqbiR7q",
        "issuerDIDDoc": {},
        "requestingPartyDIDDoc": {}
    }
}

ConsentCredential was renamed to AuthorizationCredential to align with UMA (ref: trustbloc/adapter#188).

userDID was renamed to subjectDID to be "more generic" (ref: PR #20 (comment)). I would further this with the fact that the subject of a set of claims is not necessarily the same party that authorized access to said claims (ref: #23 ).

This puts us squarely in authZ land with the resource owner decoupled from the party (human, institution, machine...) that is driving the client requesting access to the resources. AKA User-Managed Access.

In UMA, the resource owner controls (accept/reject) whether the authorization server issues a requesting party token to the requesting party. We are essentially doing the same, but relaying the RPT to the requesting party via the resource owner's wallet.

There is no "issuer" role in UMA. What there is though is "resource server". Or more generically it's the location of the resource, similar to locations in RAR.

Should we rename "issuerDIDDoc" to "location"? location falls outside of UMA but I feel it captures the meaning behind this claim quite well.

We're recently dones some changes:

• Renamed ConsentCredential -> AuthorizationCredential (ref: trustbloc/adapter#188).
• Renamed userDID -> subjectDID (ref: PR #20 (comment)).

The first change moves us in the more direction of authorization to a generic resource, not just simply authenticating the user. The second change furthers this by distinguishing the resource owner from the subject of the resource.

We're missing a way to express who authorized this access. We should add an ownerDID claim.

ownerDID != subjectDID when the resource is NOT a set of claims about the party that authorized access. Eg. Acme Bank authorizes IRS access to credit card statements about Eve.

The did:peer method spec explicitly circumvents JSON canonicalization and opts for computing the DID using the document's raw bytes. As such, transferring did:peer docs in JSON form means one cannot compute and verify the doc's contents against the ID received.

The type of DIDDoc.doc should instead be xsd:base64binary and the sender should base64-encode the document's raw bytes.

This being replaced with #61

AuthorizationCredential currently has:

1. issuerDIDDoc (which to me means "location" - see #24)
2. requestingPartyDIDDoc (PR #22)
3. subjectDID (I think should be renamed - see #25)

(missing a "resource owner" - see #23)

These things tell us:

1. The location of the resource
2. The requesting party
3. The subject of the claims in the resource

We're missing a way to express the scope of access on the resource along several dimensions:

• time (nbf, exp)
• mode (RO, RW, ...)
• granularity (specific fields inside schemas)
• others?

An initial thought was to use the DIF's presentation exchange format to express this... although it doesn't cover all of the bullets

https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0430-machine-readable-governance-frameworks#reference

subjectDIDDoc was added as part of PR in wallet. Update AuthZ to add this new field.

Currently all the example contexts are stored in one file https://github.com/trustbloc/context/blob/master/vc/examples-ext-v1.jsonld which makes it hard to maintain.

Need to create use case specific contexts.

Based on trustbloc/adapter#372 (comment)