Define DID (#16)

specifications/M1/credential.issuance.protocol.md

@@ -22,7 +22,7 @@ associated with manual workflows that are best modelled using asynchronous messa
 
 ## 1.2 Terms
 
-TBD
+- ***DID*** - A decentralized identifier as defined by the [DID specification](/~https://github.com/w3c/did-core).
 
 # 2. Overview
 

specifications/M1/identity.protocol.base.md

@@ -32,7 +32,7 @@ Decentralization is achieved in the following ways:
 # 3. Identities and Identifiers
 
 Each participant MUST have a unique, immutable **_identity_** provided by the `Registration Service` and
-a [Web DID](https://w3c-ccg.github.io/did-method-web/) that it chooses. This relationship is expressed as:
+a [DID](https://github.com/w3c/did-core) that it chooses. This relationship is expressed as:
 
 ```
 ID  ------ Can resolve to -----> DID
@@ -47,8 +47,8 @@ This immutable identity is termed the `participant id`.
 
 Dataspaces which implement the TX identity protocol MUST define a VC that adheres to
 the [Verifiable Credentials Data Model v1.1](https://www.w3.org/TR/vc-data-model/) and cryptographically binds the
-`participant id` to its `Web DID`. This VC is termed the `Membership VC`. The VC verifier's cryptographic material MUST
-be resolvable as a `Web DID`.
+`participant id` to its `DID`. This VC is termed the `Membership VC`. The VC verifier's cryptographic material MUST
+be resolvable via a `DID`.
 
 > TODO: do we want to define the subject material of the Membership VC or should we leave it dataspace specific?
 
@@ -70,7 +70,7 @@ The Self-Issued ID Token MUST adhere
 to [JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens](https://datatracker.ietf.org/doc/html/rfc9068) and MUST
 include the following claims:
 
-- The `iss` and `sub` claims MUST be equal and set to the bearer's (participant's) web DID.
+- The `iss` and `sub` claims MUST be equal and set to the bearer's (participant's) DID.
 - The `sub_jwk` claim is not used
 - The `aud` set to the `participant_id` of the relying party (RP)
 - The `client_id` set to the `participant_id` of the consumer

specifications/M1/tx.dataspace.topology.md

@@ -27,8 +27,8 @@ The DSP specifications are based on the concept that all participants have a sta
 typically a number assigned to the participant business entity. In this scheme, participant agent identities may be
 ephemeral since all operations such as signing `contract agreements`are associated with the participant identity.
 
-This specification will also make use of DIDs, which can be employed to cryptographically verify a participant identity.
-These are related as follows:
+This specification will also make use of [DIDs](/~https://github.com/w3c/did-core), which can be employed to
+cryptographically verify a participant identity. These are related as follows:
 
 ```
 ID  ------ Can resolve to -----> DID

specifications/M1/verifiable.presentation.protocol.md

@@ -30,6 +30,7 @@ issued credentials.
 - **Subject** - The target of a set of claims contained in a VC as defined by
   the [W3C VC Data Model](https://www.w3.org/TR/vc-data-model/#dfn-subjects). In a dataspace, a subject will be a
   participant.
+- ***DID*** - A decentralized identifier as defined by the [DID specification](/~https://github.com/w3c/did-core).
 
 ## 1.3. Json-Ld Context
 
@@ -174,9 +175,9 @@ If successful, credentials will be created or updated and a `200 OK` returned.
 
 # 6. CS Endpoint Resolution through DID Documents
 
-Different methods may be used by a Relying Party (as defined by the OAuth2 specification, link TBD) to resolve the Credential Service for a client. One way is
-through DID documents. If a DID document is used, the client `DID document` MUST contain at least
-one [service entry](https://www.w3.org/TR/did-core/#services) of type `CredentialService`:
+Different methods may be used by a Relying Party (as defined by the OAuth2 specification, link TBD) to resolve the
+Credential Service for a client. One way is through DID documents. If a DID document is used, the client `DID document`
+MUST contain at least one [service entry](https://www.w3.org/TR/did-core/#services) of type `CredentialService`:
 
 ```
 {