Merge pull request #102 from jimmarino/feat/cip-update

feat: Update CIP to align terminology and formatting

artifacts/src/main/resources/issuance/example/credential-request-message.json

@@ -5,9 +5,9 @@
     "https://www.w3.org/2018/credentials/examples/v1"
   ],
   "type": "CredentialRequestMessage",
-  "format": "ldp_vd",
+  "format": "jwt_vc_json",
   "credentialType": [
     "VerifiableCredential",
-    "AlumniCredential"
+    "OrganizationCredential"
   ]
 }

specifications/base.protocol.md

@@ -106,6 +106,6 @@ version and the following context URI: `https://w3id.org/dspace-dcp/v0.8`.
 
 # The Base URL
 
-All endpoint URLs in this specification are relative. The base URL is implementation-specific and may include
-additional context information such as a sub-path that disambiguates a holder.
+All endpoint URLs in this specification are relative. The base URL MUST use the HTTPS scheme. The base URL is
+implementation-specific and may include additional context information such as a sub-path that disambiguates a holder.
 

specifications/dataspace.ecosystem.md

@@ -5,7 +5,7 @@ adheres to the model defined by the Dataspace Protocol [[dsp-base]]:
 
 - The <dfn>Dataspace Authority</dfn> is responsible for operational management of the dataspace, including participant
   registration and designation of trust credential issuers.
-- A </dfn>Participant</dfn> is a member of the dataspace. Members may take on different roles, which are attested to by
+- A <dfn>Participant</dfn> is a member of the dataspace. Members may take on different roles, which are attested to by
   verifiable credentials.
 - A <dfn>Participant Agent</dfn> performs tasks such as publishing a catalog or engaging in data transfer. Note that a
   participant agent is a logical construct and does not necessarily correspond to a single runtime process.

specifications/issuance.flow.puml

@@ -7,26 +7,23 @@ autonumber
 
 box "Client Entity"
 participant "Client" as C
-participant "Credential Service" as CS
 participant "Secure Token Service" as STS
+participant "DID Service" as DS
+participant "Credential Service" as CS
 end box
 
 box "Issuer Entity"
-participant "Issuer Service(s)" as IS #FFF4B3
+participant "Issuer Service" as IS
 end box
 
-group #F3F7FF Base Identity Protocol
 C -> STS: Self-Issued ID token request
 STS -> C: Token response w/ access token
-end
-
-'#E6F8E9
-group #FFF4B3 Issuance Protocol
-C -> IS: Request Credential using Self-Issued ID token
-group #E6F8E9 Verifiable Presentation Protocol
-IS -> CS: (async) )Write Membership Credential
-end
-end
+C -> IS: Request credential(s) using Self-Issued ID token
+DS <- IS: Resolve DID
+DS -> IS: DID document response
+C <- IS: Ack
+CS <- IS: (async) Write credential(s)\n w/ access token
+CS -> CS: Validate token and\n store credentials
 
 
 @enduml

specifications/verifiable.presentation.protocol.md

@@ -26,7 +26,7 @@ The following sequence diagram depicts a non-normative flow where a client inter
    client wants the Verifier to have access to. This set of scopes is determined out of band and may be derived from
    metadata the verifier has previously made available to the client.
 2. The [=Secure Token Service=] responds with the Self-Signed ID token containing a `token` claim with the value set to
-   an access token. The access token can be used by the verifier to request Verifiable Credentials from the client's
+   an access token. The access token can be used by the verifier to request [=Verifiable Credentials=] from the client's
    Credential Service.
 3. The client makes a request to the [=Verifier=] for a protected resource and includes the [=Self-Issued ID Token=].
 4. The [=Verifier=] resolves the client [=DID=] based on the value of the [=Self-Issued ID Token=] `sub` claim.