A Credential Status provides enough information to determine the current status of the credential (for example, suspended or revoked). It MUST include the `id` property, which MUST be a URL, and the `type` property, which expresses the credential status type (also referred to as the credential status scheme)
A Credential Evidence scheme provides enough information to a verifier to determine whether the evidence gathered meets their requirements for issuing a credential. The precise content of each evidence scheme is determined by the specific evidence type definition.
A Credential is a set of one or more claims made by an issuer. A Verifiable Credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable Credentials can be used to build Verifiable Presentations, which can also be cryptographically verified.
A Presentation is data derived from one or more Credentials, issued by one or more `issuers`, that is shared with a specific `verifier`. A Verifiable Presentation is a tamper-evident Presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs).
A Credential Status provides enough information to determine the current status of the credential (for example, suspended or revoked). It MUST include the `id` property, which MUST be a URL, and the `type` property, which expresses the credential status type (also referred to as the credential status scheme)
A Credential Evidence scheme provides enough information to a verifier to determine whether the evidence gathered meets their requirements for issuing a credential. The precise content of each evidence scheme is determined by the specific evidence type definition.
A Credential is a set of one or more claims made by an issuer. A Verifiable Credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable Credentials can be used to build Verifiable Presentations, which can also be cryptographically verified.
A Presentation is data derived from one or more Credentials, issued by one or more `issuers`, that is shared with a specific `verifier`. A Verifiable Presentation is a tamper-evident Presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs).
The value of the `holder` property MUST be a URI. It is RECOMMENDED that dereferencing the URI results in a document containing machine-readable information about the holder that can be used to verify the information expressed in the credential.
The property's value should be a URL, i.e., not a literal.
The value of the `issued` property MUST be a string value of an ISO8601 combined date and time string representing the date and time the credential was issued. Note that this date represents the earliest date when the information associated with the
The value of the `issuer` property MUST be a URI. It is RECOMMENDED that dereferencing the URI results in a document containing machine-readable information about the issuer that can be used to verify the information expressed in the credential.
The property's value should be a URL, i.e., not a literal.
If specified, the value of the optional `termsOfUse` property MUST specify one or more terms of use policies under which the issuer issued the credential or presentation. Each `termsOfUse` policy MUST specify its type (for example, `IssuerPolicy`) and MAY specify its instance `id`. The precise content of each term of use is determined by the specific `TermsOfUse` type definition. If the recipient (a holder or verifier) violates the specified terms of use, the responsibility is their own, and such violation may incur legal liability.
The value of the `validFrom` property MUST be a string value of an ISO8601 combined date and time string representing the date and time the credential was issued. Note that this date represents the earliest date when the information associated with the
The value of the `validUntil` property MUST be a string value of an ISO8601 combined date and time string representing the date and time the credential ceases to be valid.
The value of the `holder` property MUST be a URI. It is RECOMMENDED that dereferencing the URI results in a document containing machine-readable information about the holder that can be used to verify the information expressed in the credential.
The property's value should be a URL, i.e., not a literal.
The value of the `issued` property MUST be a string value of an ISO8601 combined date and time string representing the date and time the credential was issued. Note that this date represents the earliest date when the information associated with the
The value of the `issuer` property MUST be a URI. It is RECOMMENDED that dereferencing the URI results in a document containing machine-readable information about the issuer that can be used to verify the information expressed in the credential.
The property's value should be a URL, i.e., not a literal.
If specified, the value of the optional `termsOfUse` property MUST specify one or more terms of use policies under which the issuer issued the credential or presentation. Each `termsOfUse` policy MUST specify its type (for example, `IssuerPolicy`) and MAY specify its instance `id`. The precise content of each term of use is determined by the specific `TermsOfUse` type definition. If the recipient (a holder or verifier) violates the specified terms of use, the responsibility is their own, and such violation may incur legal liability.
The value of the `validFrom` property MUST be a string value of an ISO8601 combined date and time string representing the date and time the credential was issued. Note that this date represents the earliest date when the information associated with the
The value of the `validUntil` property MUST be a string value of an ISO8601 combined date and time string representing the date and time the credential ceases to be valid.
The following are deprecated property definitions in the cred namespace:
expirationDate
Expiration date (deprecated)
The value of the `expirationDate` property was used to express the date and time the credential ceases to be valid. It has been deprecated in favor of `validUntil`
The value of the `issuanceDate` property was used to represents the earliest date when the information associated with the `credentialSubject` property became valid. This property has been deprecated in favour of `validFrom`.
The following are deprecated property definitions in the cred namespace.
expirationDate
Expiration date (deprecated)
The value of the `expirationDate` property was used to express the date and time the credential ceases to be valid. It has been deprecated in favor of `validUntil`
The value of the `issuanceDate` property was used to represents the earliest date when the information associated with the `credentialSubject` property became valid. This property has been deprecated in favour of `validFrom`.
The value of the `holder` property MUST be a URI. It is RECOMMENDED that dereferencing the URI results in a document containing machine-readable information about the holder that can be used to verify the information expressed in the credential.
The value of the `issuer` property MUST be a URI. It is RECOMMENDED that dereferencing the URI results in a document containing machine-readable information about the issuer that can be used to verify the information expressed in the credential.
A Verification Method class can express different verification methods, such as cryptographic public keys, which can be used to authenticate or authorize interaction with the `controller` or associated parties. Verification methods might take many parameters.
A Verification Method class can express different verification methods, such as cryptographic public keys, which can be used to authenticate or authorize interaction with the `controller` or associated parties. Verification methods might take many parameters.
The `domain` property is used to associate a domain with a proof, for use with a `proofPurpose` such as `authentication` and indicating its intended usage.
The challenge property is used to associate a challenge with a proof, for use with a `proofPurpose` such as `authentication`. This string value SHOULD be included in a proof if a `domain` is specified.
The` proofPurpose` property is used to associate a purpose, such as `assertionMethod` or `authentication` with a proof. The proof purpose acts as a safeguard to prevent the proof from being misused by being applied to a purpose other than the one that was intended.
The value of the `proof` property MUST identify `ProofGraph` instances (informally, it indirectly identifies `Proof` instances, each contained in a separate graph). The property is used to associate a proof with a graph of information. The proof property is typically not included in the canonicalized graphs that are then digested and digitally signed. The order of the proofs is not relevant.
The value of the `proofChain` property MUST identify a sequence of `ProofGraph` instances (informally, it indirectly identifies a series of `Proof` instances, each contained in a separate graph). The property is used to provide a sequence of multiple proofs where the order of when the proofs occurred matters. The proof chain property is typically not included in the canonicalized graphs that are then separately digested and digitally signed.
stable
Range:
rdf:List
controller
Controller
A controller is an entity that claims control over a particular resource. Note that control is best validated as a two-way relationship, where the controller claims control over a particular resource, and the resource clearly identifies its controller.
The property's value should be a URL, i.e., not a literal.
A `capabilityDelegation` property is used to express that one or more `verificationMethods` are authorized to verify cryptographic proofs that were created for the purpose of delegating capabilities.
+
The following are property definitions in the sec namespace.
verificationMethod
Verification method
A `verificationMethod` property is used to specify a URL that contains information used for proof verification.
The `domain` property is used to associate a domain with a proof, for use with a `proofPurpose` such as `authentication` and indicating its intended usage.
The challenge property is used to associate a challenge with a proof, for use with a `proofPurpose` such as `authentication`. This string value SHOULD be included in a proof if a `domain` is specified.
The` proofPurpose` property is used to associate a purpose, such as `assertionMethod` or `authentication` with a proof. The proof purpose acts as a safeguard to prevent the proof from being misused by being applied to a purpose other than the one that was intended.
The value of the `proof` property MUST identify `ProofGraph` instances (informally, it indirectly identifies `Proof` instances, each contained in a separate graph). The property is used to associate a proof with a graph of information. The proof property is typically not included in the canonicalized graphs that are then digested and digitally signed. The order of the proofs is not relevant.
The value of the `proofChain` property MUST identify a sequence of `ProofGraph` instances (informally, it indirectly identifies a series of `Proof` instances, each contained in a separate graph). The property is used to provide a sequence of multiple proofs where the order of when the proofs occurred matters. The proof chain property is typically not included in the canonicalized graphs that are then separately digested and digitally signed.
stable
Range:
rdf:List
controller
Controller
A controller is an entity that claims control over a particular resource. Note that control is best validated as a two-way relationship, where the controller claims control over a particular resource, and the resource clearly identifies its controller.
The property's value should be a URL, i.e., not a literal.
A `capabilityDelegation` property is used to express that one or more `verificationMethods` are authorized to verify cryptographic proofs that were created for the purpose of delegating capabilities.
A `verificationMethod` may be referenced by its identifier (a URL) or expressed in full.
-
The aforementioned proofs are created to prove that some entity is delegating the authority to take some action to another entity. A verifier of the proof should expect the proof to express a `proofPurpose` of `capabilityDelegation` and reference a `verificationMethod` to verify it. The dereferenced `verificationMethod` MUST have a controller property that has a property of `capabilityDelegation` that references the `verificationMethod`. This indicates that the controller has authorized it for the expressed `proofPurpose`.
A `capabilityInvocation` property is used to express that one or more `verificationMethods` are authorized to verify cryptographic proofs that were created for the purpose of invoking capabilities.
+
The aforementioned proofs are created to prove that some entity is delegating the authority to take some action to another entity. A verifier of the proof should expect the proof to express a `proofPurpose` of `capabilityDelegation` and reference a `verificationMethod` to verify it. The dereferenced `verificationMethod` MUST have a controller property that has a property of `capabilityDelegation` that references the `verificationMethod`. This indicates that the controller has authorized it for the expressed `proofPurpose`.
A `capabilityInvocation` property is used to express that one or more `verificationMethods` are authorized to verify cryptographic proofs that were created for the purpose of invoking capabilities.
A `verificationMethod` MAY be referenced by its identifier (a URL) or expressed in full.
-
The aforementioned proofs are created to prove that some entity is attempting to exercise some authority they possess to take an action. A verifier of the proof should expect the proof to express a `proofPurpose` of `capabilityInvocation` and reference a `verificationMethod` to verify it. The dereferenced `verificationMethod` MUST have a controller property that, when dereferenced, has a property of `capabilityInvocation` that references the `verificationMethod.` This indicates that the controller has authorized it for the expressed `proofPurpose`.
Indicates that a proof is used for for key agreement protocols, such as Elliptic Curve Diffie Hellman key agreement used by popular encryption libraries.
The public key multibase property is used to specify the multibase-encoded version of a public key. The contents of the property are defined by specifications such as ED25519-2020 and listed in the Linked Data Cryptosuite Registry. Most public key type definitions are expected to:
+
The aforementioned proofs are created to prove that some entity is attempting to exercise some authority they possess to take an action. A verifier of the proof should expect the proof to express a `proofPurpose` of `capabilityInvocation` and reference a `verificationMethod` to verify it. The dereferenced `verificationMethod` MUST have a controller property that, when dereferenced, has a property of `capabilityInvocation` that references the `verificationMethod.` This indicates that the controller has authorized it for the expressed `proofPurpose`.
Indicates that a proof is used for for key agreement protocols, such as Elliptic Curve Diffie Hellman key agreement used by popular encryption libraries.
The public key multibase property is used to specify the multibase-encoded version of a public key. The contents of the property are defined by specifications such as ED25519-2020 and listed in the Linked Data Cryptosuite Registry. Most public key type definitions are expected to:
Specify only a single encoding base per public key type as it reduces implementation burden and increases the chances of reaching broad interoperability.
Specify a multicodec header on the encoded public key to aid encoding and decoding applications in confirming that they are serializing and deserializing an expected public key type.
Use compressed binary formats to ensure efficient key sizes.
-
This class represents a digital signature on serialized data. It is an abstract class and should not be used other than for Semantic Web reasoning purposes, such as by a reasoning agent. This class MUST NOT be used directly, but only through its subclasses.
This class represents a message digest that may be used for data integrity verification. The digest algorithm used will determine the cryptographic properties of the digest.
deprecatedtrue
EncryptedMessage
Encrypted message (deprecated)
A class of messages that are obfuscated in some cryptographic manner. These messages are incredibly difficult to decrypt without the proper decryption key.
A graph signature is used for digital signatures on RDF graphs. The default canonicalization mechanism is specified in the RDF Graph normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and RSA to perform the digital signature.
Linked data signature, 2015 version (was deprecated in the CCG document) (deprecated)
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and RSA to perform the digital signature.
Linked data signature, 2016 version (was deprecated in the CCG document) (deprecated)
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and RSA to perform the digital signature.
Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and ECDSA to perform the digital signature.
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and JWS to perform the digital signature.
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which deterministically names all unnamed nodes. Importantly, a `BbsBlsSignature` digests each of the statements produced by the normalization process individually to enable selective disclosure. The signature mechanism uses Blake2B as the digest for each statement and produces a single output digital signature.
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which deterministically names all unnamed nodes. Importantly, a `BbsBlsSignatureProof2020` is in fact a proof of knowledge of an unrevealed BbsBlsSignature2020 enabling the ability to selectively reveal information from the set that was originally signed. Each of the statements produced by the normalizing process for a JSON-LD document featuring a `BbsBlsSignatureProof2020` represent statements that were originally signed in producing the `BbsBlsSignature2020` and represent the denomination under which information can be selectively disclosed. The signature mechanism uses Blake2B as the digest for each statement and produces a single output digital signature.
This class represents a digital signature on serialized data. It is an abstract class and should not be used other than for Semantic Web reasoning purposes, such as by a reasoning agent. This class MUST NOT be used directly, but only through its subclasses.
This class represents a message digest that may be used for data integrity verification. The digest algorithm used will determine the cryptographic properties of the digest.
deprecatedtrue
EncryptedMessage
Encrypted message (deprecated)
A class of messages that are obfuscated in some cryptographic manner. These messages are incredibly difficult to decrypt without the proper decryption key.
A graph signature is used for digital signatures on RDF graphs. The default canonicalization mechanism is specified in the RDF Graph normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and RSA to perform the digital signature.
Linked data signature, 2015 version (was deprecated in the CCG document) (deprecated)
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and RSA to perform the digital signature.
Linked data signature, 2016 version (was deprecated in the CCG document) (deprecated)
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and RSA to perform the digital signature.
Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and ECDSA to perform the digital signature.
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and JWS to perform the digital signature.
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which deterministically names all unnamed nodes. Importantly, a `BbsBlsSignature` digests each of the statements produced by the normalization process individually to enable selective disclosure. The signature mechanism uses Blake2B as the digest for each statement and produces a single output digital signature.
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which deterministically names all unnamed nodes. Importantly, a `BbsBlsSignatureProof2020` is in fact a proof of knowledge of an unrevealed BbsBlsSignature2020 enabling the ability to selectively reveal information from the set that was originally signed. Each of the statements produced by the normalizing process for a JSON-LD document featuring a `BbsBlsSignatureProof2020` represent statements that were originally signed in producing the `BbsBlsSignature2020` and represent the denomination under which information can be selectively disclosed. The signature mechanism uses Blake2B as the digest for each statement and produces a single output digital signature.
The following are deprecated property definitions in the sec namespace:
cipherAlgorithm
Cipher algorithm (deprecated)
The cipher algorithm describes the mechanism used to encrypt a message. It is typically a string expressing the cipher suite, the strength of the cipher, and a block cipher mode.
The digest algorithm is used to specify the cryptographic function to use when generating the data to be digitally signed. Typically, data that is to be signed goes through three steps: 1) canonicalization, 2) digest, and 3) signature. This property is used to specify the algorithm that should be used for step 2. A signature class typically specifies a default digest method, so this property is typically used to specify information for a signature algorithm.
deprecatedtrue
Range:
xsd:string
digestValue
Digest value (deprecated)
The digest value is used to express the output of the digest algorithm expressed in Base-16 (hexadecimal) format.
deprecatedtrue
Range:
xsd:string
blockchainAccountId
Blockchain account ID (deprecated)
A `blockchainAccountId` property is used to specify a blockchain account identifier, as per the CAIP-10Account ID Specification.
deprecatedtrue
Range:
xsd:string
ethereumAddress
Ethereum address (deprecated)
An `ethereumAddress` property is used to specify the Ethereum address. As per the Ethereum Yellow Paper “Ethereum: a secure decentralised generalised transaction ledger” in consists of a prefix "0x", a common identifier for hexadecimal, concatenated with the rightmost 20 bytes of the Keccak-256 hash (big endian) of the ECDSA public key (the curve used is the so-called secp256k1). In hexadecimal, 2 digits represent a byte, meaning addresses contain 40 hexadecimal digits. The Ethereum address should also contain a checksum as per EIP-55.
The expiration time is typically associated with a `Key` and specifies when the validity of the key will expire.
deprecatedtrue
Range:
xsd:dateTime
initializationVector
Initialization vector (deprecated)
The initialization vector (IV) is a byte stream that is typically used to initialize certain block cipher encryption schemes. For a receiving application to be able to decrypt a message, it must know the decryption key and the initialization vector. The value is typically base-64 encoded.
This property is used in conjunction with the input to the signature hashing function in order to protect against replay attacks. Typically, receivers need to track all nonce values used within a certain time period in order to ensure that an attacker cannot merely re-send a compromised packet in order to execute a privileged request.
The canonicalization algorithm is used to transform the input data into a form that can be passed to a cryptographic digest method. The digest is then digitally signed using a digital signature algorithm. Canonicalization ensures that a piece of software that is generating a digital signature is able to do so on the same set of information in a deterministic manner.
A controller is an entity that claims control over a particular resource. Note that control is best validated as a two-way relationship where the controller claims control over a particular resource, and the resource clearly identifies its controller.
The property's value should be a URL, i.e., not a literal.
deprecatedtrue
owner
Owner (was deprecated in the CCG document) (deprecated)
An owner is an entity that claims control over a particular resource. Note that ownership is best validated as a two-way relationship where the owner claims ownership over a particular resource, and the resource clearly identifies its owner.
The property's value should be a URL, i.e., not a literal.
deprecatedtrue
password
Password (deprecated)
A secret that is used to generate a key that can be used to encrypt or decrypt message. It is typically a string value.
deprecatedtrue
Range:
xsd:string
privateKeyPem
PEM encoded private key (deprecated)
A private key PEM property is used to specify the PEM-encoded version of the private key. This encoding is compatible with almost every Secure Sockets Layer library implementation and typically plugs directly into functions intializing private keys.
A public key PEM property is used to specify the PEM-encoded version of the public key. This encoding is compatible with almost every Secure Sockets Layer library implementation and typically plugs directly into functions initializing public keys.
A `publicKeyHex` property is used to specify the hex-encoded version of the public key, based on section 8 of rfc4648. Hex encoding is also known as Base16 encoding.
The publicKeyService property is used to express the REST URL that provides public key management services.
The property's value should be a URL, i.e., not a literal.
deprecatedtrue
revoked
Revocation time (deprecated)
The revocation time is typically associated with a `Key` that has been marked as invalid as of the date and time associated with the property. Key revocations are often used when a key is compromised, such as the theft of the private key, or during the course of best-practice key rotation schedules.
deprecatedtrue
Range:
xsd:dateTime
jws
Json Web Signature (deprecated)
The jws property is used to associate a detached Json Web Signature with a proof.
The challenge property is used to associate a challenge with a proof, for use with a `proofPurpose` such as `authentication`. This string value SHOULD be included in a proof if a `domain` is specified.
Signature (was deprecated in the CCG document) (deprecated)
The property is used to associate a proof with a graph of information. The proof property is typically not included in the canonicalized graph that is then digested, and digitally signed.
Signature algorithm (was deprecated in the CCG document) (deprecated)
The signature algorithm is used to specify the cryptographic signature function to use when digitally signing the digest data. Typically, text to be signed goes through three steps: 1) canonicalization, 2) digest, and 3) signature. This property is used to specify the algorithm that should be used for step #3. A signature class typically specifies a default signature algorithm, so this property rarely needs to be used in practice when specifying digital signatures.
The property's value should be a URL, i.e., not a literal.
A network address at which a service operates on behalf of a controller. Examples of specific services include discovery services, social networks, file storage services, and verifiable claim repository services. Service endpoints might also be provided by a generalized data interchange protocol, such as extensible data interchange.
The property's value should be a URL, i.e., not a literal.
The x509CertificateChain property is used to associate a chain of X.509 Certificates with a proof. The value of this property is an ordered list where each value in the list is an X.509 Certificate expressed as a DER PKIX format, that is encoded with multibase using the base64pad variant. The certificate directly associated to the verification method used to verify the proof MUST be the first element in the list. Subsequent certificates in the list MAY be included where each one MUST certify the previous one.
The x509CertificateFingerprint property is used to associate an X.509 Certificate with a proof via its fingerprint. The value is a multihash encoded then multibase encoded value using the base64pad variant. It is RECOMMENDED that the fingerprint value be the SHA-256 hash of the X.509 Certificate.
The following are deprecated property definitions in the sec namespace.
cipherAlgorithm
Cipher algorithm (deprecated)
The cipher algorithm describes the mechanism used to encrypt a message. It is typically a string expressing the cipher suite, the strength of the cipher, and a block cipher mode.
The digest algorithm is used to specify the cryptographic function to use when generating the data to be digitally signed. Typically, data that is to be signed goes through three steps: 1) canonicalization, 2) digest, and 3) signature. This property is used to specify the algorithm that should be used for step 2. A signature class typically specifies a default digest method, so this property is typically used to specify information for a signature algorithm.
deprecatedtrue
Range:
xsd:string
digestValue
Digest value (deprecated)
The digest value is used to express the output of the digest algorithm expressed in Base-16 (hexadecimal) format.
deprecatedtrue
Range:
xsd:string
blockchainAccountId
Blockchain account ID (deprecated)
A `blockchainAccountId` property is used to specify a blockchain account identifier, as per the CAIP-10Account ID Specification.
deprecatedtrue
Range:
xsd:string
ethereumAddress
Ethereum address (deprecated)
An `ethereumAddress` property is used to specify the Ethereum address. As per the Ethereum Yellow Paper “Ethereum: a secure decentralised generalised transaction ledger” in consists of a prefix "0x", a common identifier for hexadecimal, concatenated with the rightmost 20 bytes of the Keccak-256 hash (big endian) of the ECDSA public key (the curve used is the so-called secp256k1). In hexadecimal, 2 digits represent a byte, meaning addresses contain 40 hexadecimal digits. The Ethereum address should also contain a checksum as per EIP-55.
The expiration time is typically associated with a `Key` and specifies when the validity of the key will expire.
deprecatedtrue
Range:
xsd:dateTime
initializationVector
Initialization vector (deprecated)
The initialization vector (IV) is a byte stream that is typically used to initialize certain block cipher encryption schemes. For a receiving application to be able to decrypt a message, it must know the decryption key and the initialization vector. The value is typically base-64 encoded.
This property is used in conjunction with the input to the signature hashing function in order to protect against replay attacks. Typically, receivers need to track all nonce values used within a certain time period in order to ensure that an attacker cannot merely re-send a compromised packet in order to execute a privileged request.
The canonicalization algorithm is used to transform the input data into a form that can be passed to a cryptographic digest method. The digest is then digitally signed using a digital signature algorithm. Canonicalization ensures that a piece of software that is generating a digital signature is able to do so on the same set of information in a deterministic manner.
A controller is an entity that claims control over a particular resource. Note that control is best validated as a two-way relationship where the controller claims control over a particular resource, and the resource clearly identifies its controller.
The property's value should be a URL, i.e., not a literal.
deprecatedtrue
owner
Owner (was deprecated in the CCG document) (deprecated)
An owner is an entity that claims control over a particular resource. Note that ownership is best validated as a two-way relationship where the owner claims ownership over a particular resource, and the resource clearly identifies its owner.
The property's value should be a URL, i.e., not a literal.
deprecatedtrue
password
Password (deprecated)
A secret that is used to generate a key that can be used to encrypt or decrypt message. It is typically a string value.
deprecatedtrue
Range:
xsd:string
privateKeyPem
PEM encoded private key (deprecated)
A private key PEM property is used to specify the PEM-encoded version of the private key. This encoding is compatible with almost every Secure Sockets Layer library implementation and typically plugs directly into functions intializing private keys.
A public key PEM property is used to specify the PEM-encoded version of the public key. This encoding is compatible with almost every Secure Sockets Layer library implementation and typically plugs directly into functions initializing public keys.
A `publicKeyHex` property is used to specify the hex-encoded version of the public key, based on section 8 of rfc4648. Hex encoding is also known as Base16 encoding.
The publicKeyService property is used to express the REST URL that provides public key management services.
The property's value should be a URL, i.e., not a literal.
deprecatedtrue
revoked
Revocation time (deprecated)
The revocation time is typically associated with a `Key` that has been marked as invalid as of the date and time associated with the property. Key revocations are often used when a key is compromised, such as the theft of the private key, or during the course of best-practice key rotation schedules.
deprecatedtrue
Range:
xsd:dateTime
jws
Json Web Signature (deprecated)
The jws property is used to associate a detached Json Web Signature with a proof.
The challenge property is used to associate a challenge with a proof, for use with a `proofPurpose` such as `authentication`. This string value SHOULD be included in a proof if a `domain` is specified.
Signature (was deprecated in the CCG document) (deprecated)
The property is used to associate a proof with a graph of information. The proof property is typically not included in the canonicalized graph that is then digested, and digitally signed.
Signature algorithm (was deprecated in the CCG document) (deprecated)
The signature algorithm is used to specify the cryptographic signature function to use when digitally signing the digest data. Typically, text to be signed goes through three steps: 1) canonicalization, 2) digest, and 3) signature. This property is used to specify the algorithm that should be used for step #3. A signature class typically specifies a default signature algorithm, so this property rarely needs to be used in practice when specifying digital signatures.
The property's value should be a URL, i.e., not a literal.
A network address at which a service operates on behalf of a controller. Examples of specific services include discovery services, social networks, file storage services, and verifiable claim repository services. Service endpoints might also be provided by a generalized data interchange protocol, such as extensible data interchange.
The property's value should be a URL, i.e., not a literal.
The x509CertificateChain property is used to associate a chain of X.509 Certificates with a proof. The value of this property is an ordered list where each value in the list is an X.509 Certificate expressed as a DER PKIX format, that is encoded with multibase using the base64pad variant. The certificate directly associated to the verification method used to verify the proof MUST be the first element in the list. Subsequent certificates in the list MAY be included where each one MUST certify the previous one.
The x509CertificateFingerprint property is used to associate an X.509 Certificate with a proof via its fingerprint. The value is a multihash encoded then multibase encoded value using the base64pad variant. It is RECOMMENDED that the fingerprint value be the SHA-256 hash of the X.509 Certificate.
deprecatedtrue
diff --git a/example/security.jsonld b/example/security.jsonld
index dfc39d3..8c05011 100644
--- a/example/security.jsonld
+++ b/example/security.jsonld
@@ -63,18 +63,30 @@
"rdfs_instances": {
"@reverse": "rdfs:isDefinedBy",
"@type": "@id"
+ },
+ "rdfs_datatypes": {
+ "@reverse": "rdfs:isDefinedBy",
+ "@type": "@id"
+ },
+ "dc:title": {
+ "@container": "@language"
+ },
+ "dc:description": {
+ "@container": "@language"
}
},
"@id": "https://w3id.org/security/v1",
"@type": "owl:Ontology",
"dc:title": {
- "en": "Security Vocabulary"
+ "@value": "Security Vocabulary",
+ "@language": "en"
},
"dc:description": {
- "en": "vocabulary used to ensure the authenticity and integrity of Verifiable Credentials and similar types of constrained digital documents using cryptography, especially through the use of digital signatures and related mathematical proofs \n"
+ "@value": "vocabulary used to ensure the authenticity and integrity of Verifiable Credentials and similar types of constrained digital documents using cryptography, especially through the use of digital signatures and related mathematical proofs \n",
+ "@language": "en"
},
"rdfs:seeAlso": "https://www.w3.org/TR/vc-data-integrity/",
- "dc:date": "2023-04-14",
+ "dc:date": "2023-12-13",
"rdfs_classes": [
{
"@id": "sec:Proof",
@@ -636,7 +648,7 @@
"rdfs_properties": [
{
"@id": "sec:verificationMethod",
- "@type": "rdfs:Property",
+ "@type": "rdf:Property",
"rdfs:range": "sec:VerificationMethod",
"rdfs:label": "Verification method",
"rdfs:comment": {
@@ -651,7 +663,7 @@
{
"@id": "sec:domain",
"@type": [
- "rdfs:Property",
+ "rdf:Property",
"owl:DatatypeProperty"
],
"rdfs:domain": "sec:Proof",
@@ -666,7 +678,7 @@
{
"@id": "sec:challenge",
"@type": [
- "rdfs:Property",
+ "rdf:Property",
"owl:DatatypeProperty"
],
"rdfs:domain": "sec:Proof",
@@ -681,7 +693,7 @@
{
"@id": "sec:proofPurpose",
"@type": [
- "rdfs:Property",
+ "rdf:Property",
"owl:DatatypeProperty"
],
"rdfs:domain": "sec:Proof",
@@ -696,7 +708,7 @@
{
"@id": "sec:proofValue",
"@type": [
- "rdfs:Property",
+ "rdf:Property",
"owl:DatatypeProperty"
],
"rdfs:domain": "sec:Proof",
@@ -710,7 +722,7 @@
},
{
"@id": "sec:proof",
- "@type": "rdfs:Property",
+ "@type": "rdf:Property",
"rdfs:range": "sec:ProofGraph",
"rdfs:label": "Proof sets",
"rdfs:comment": {
@@ -721,7 +733,7 @@
},
{
"@id": "sec:proofChain",
- "@type": "rdfs:Property",
+ "@type": "rdf:Property",
"rdfs:range": "rdf:List",
"rdfs:label": "Proof chain",
"rdfs:comment": {
@@ -733,7 +745,7 @@
{
"@id": "sec:controller",
"@type": [
- "rdfs:Property",
+ "rdf:Property",
"owl:ObjectProperty"
],
"rdfs:domain": "sec:VerificationMethod",
@@ -746,7 +758,7 @@
},
{
"@id": "sec:authentication",
- "@type": "rdfs:Property",
+ "@type": "rdf:Property",
"rdfs:range": "VerificationMethod",
"rdfs:label": "Authentication method",
"rdfs:comment": {
@@ -757,7 +769,7 @@
},
{
"@id": "sec:assertionMethod",
- "@type": "rdfs:Property",
+ "@type": "rdf:Property",
"rdfs:range": "VerificationMethod",
"rdfs:label": "Assertion method",
"rdfs:comment": {
@@ -768,7 +780,7 @@
},
{
"@id": "sec:capabilityDelegation",
- "@type": "rdfs:Property",
+ "@type": "rdf:Property",
"rdfs:range": "VerificationMethod",
"rdfs:label": "Capability Delegation Method",
"rdfs:comment": {
@@ -779,7 +791,7 @@
},
{
"@id": "sec:capabilityInvocation",
- "@type": "rdfs:Property",
+ "@type": "rdf:Property",
"rdfs:range": "VerificationMethod",
"rdfs:label": "Capability Invocation Method",
"rdfs:comment": {
@@ -790,7 +802,7 @@
},
{
"@id": "sec:keyAgreement",
- "@type": "rdfs:Property",
+ "@type": "rdf:Property",
"rdfs:range": "VerificationMethod",
"rdfs:label": "Key agreement protocols",
"rdfs:comment": {
@@ -802,7 +814,7 @@
{
"@id": "sec:cryptosuite",
"@type": [
- "rdfs:Property",
+ "rdf:Property",
"owl:DatatypeProperty"
],
"rdfs:domain": "sec:DataIntegrityProof",
@@ -820,7 +832,7 @@
{
"@id": "sec:publicKeyMultibase",
"@type": [
- "rdfs:Property",
+ "rdf:Property",
"owl:DatatypeProperty"
],
"rdfs:domain": "sec:VerificationMethod",
@@ -841,7 +853,7 @@
{
"@id": "sec:publicKeyJwk",
"@type": [
- "rdfs:Property",
+ "rdf:Property",
"owl:DatatypeProperty"
],
"rdfs:domain": "sec:VerificationMethod",
diff --git a/example/security.ttl b/example/security.ttl
index 64cd8b6..7832f59 100644
--- a/example/security.ttl
+++ b/example/security.ttl
@@ -9,11 +9,11 @@
# Ontology definition
sec: a owl:Ontology ;
- dc:title """Security Vocabulary""" ;
+ dc:title """Security Vocabulary"""@en ;
dc:description """vocabulary used to ensure the authenticity and integrity of Verifiable Credentials and similar types of constrained digital documents using cryptography, especially through the use of digital signatures and related mathematical proofs
-""" ;
+"""@en ;
rdfs:seeAlso ;
- dc:date "2023-04-14"^^xsd:date ;
+ dc:date "2023-12-13"^^xsd:date ;
.
# Class definitions
@@ -317,7 +317,7 @@ sec:Bls12381G2Key2020 a rdfs:Class, owl:DeprecatedClass ;
# Property definitions
-sec:verificationMethod a rdfs:Property ;
+sec:verificationMethod a rdf:Property ;
rdfs:range sec:VerificationMethod ;
rdfs:label "Verification method" ;
rdfs:comment """
A `verificationMethod` property is used to specify a URL that contains information used for proof verification.
"""^^rdf:HTML ;
@@ -326,7 +326,7 @@ sec:verificationMethod a rdfs:Property ;
rdfs:seeAlso ;
.
-sec:domain a rdfs:Property, owl:DatatypeProperty ;
+sec:domain a rdf:Property, owl:DatatypeProperty ;
rdfs:domain sec:Proof ;
rdfs:range xsd:string ;
rdfs:label "Domain of a proof" ;
@@ -335,7 +335,7 @@ sec:domain a rdfs:Property, owl:DatatypeProperty ;
vs:term_status "stable" ;
.
-sec:challenge a rdfs:Property, owl:DatatypeProperty ;
+sec:challenge a rdf:Property, owl:DatatypeProperty ;
rdfs:domain sec:Proof ;
rdfs:range xsd:string ;
rdfs:label "Challenge with a proof" ;
@@ -344,7 +344,7 @@ sec:challenge a rdfs:Property, owl:DatatypeProperty ;
vs:term_status "stable" ;
.
-sec:proofPurpose a rdfs:Property, owl:DatatypeProperty ;
+sec:proofPurpose a rdf:Property, owl:DatatypeProperty ;
rdfs:domain sec:Proof ;
rdfs:range xsd:string ;
rdfs:label "Proof purpose" ;
@@ -353,7 +353,7 @@ sec:proofPurpose a rdfs:Property, owl:DatatypeProperty ;
vs:term_status "stable" ;
.
-sec:proofValue a rdfs:Property, owl:DatatypeProperty ;
+sec:proofValue a rdf:Property, owl:DatatypeProperty ;
rdfs:domain sec:Proof ;
rdfs:range xsd:string ;
rdfs:label "Proof value" ;
@@ -362,7 +362,7 @@ sec:proofValue a rdfs:Property, owl:DatatypeProperty ;
vs:term_status "stable" ;
.
-sec:proof a rdfs:Property ;
+sec:proof a rdf:Property ;
rdfs:range sec:ProofGraph ;
rdfs:label "Proof sets" ;
rdfs:comment """
The value of the `proof` property MUST identify `ProofGraph` instances (informally, it indirectly identifies `Proof` instances, each contained in a separate graph). The property is used to associate a proof with a graph of information. The proof property is typically not included in the canonicalized graphs that are then digested and digitally signed. The order of the proofs is not relevant.
The value of the `proofChain` property MUST identify a sequence of `ProofGraph` instances (informally, it indirectly identifies a series of `Proof` instances, each contained in a separate graph). The property is used to provide a sequence of multiple proofs where the order of when the proofs occurred matters. The proof chain property is typically not included in the canonicalized graphs that are then separately digested and digitally signed.
A controller is an entity that claims control over a particular resource. Note that control is best validated as a two-way relationship, where the controller claims control over a particular resource, and the resource clearly identifies its controller.
A `capabilityDelegation` property is used to express that one or more `verificationMethods` are authorized to verify cryptographic proofs that were created for the purpose of delegating capabilities.
@@ -412,7 +412,7 @@ sec:capabilityDelegation a rdfs:Property ;
vs:term_status "stable" ;
.
-sec:capabilityInvocation a rdfs:Property ;
+sec:capabilityInvocation a rdf:Property ;
rdfs:range VerificationMethod ;
rdfs:label "Capability Invocation Method" ;
rdfs:comment """
A `capabilityInvocation` property is used to express that one or more `verificationMethods` are authorized to verify cryptographic proofs that were created for the purpose of invoking capabilities.
@@ -422,7 +422,7 @@ sec:capabilityInvocation a rdfs:Property ;
vs:term_status "stable" ;
.
-sec:keyAgreement a rdfs:Property ;
+sec:keyAgreement a rdf:Property ;
rdfs:range VerificationMethod ;
rdfs:label "Key agreement protocols" ;
rdfs:comment """
Indicates that a proof is used for for key agreement protocols, such as Elliptic Curve Diffie Hellman key agreement used by popular encryption libraries.
A Verification Method class can express different verification methods, such as cryptographic public keys, which can be used to authenticate or authorize interaction with the `controller` or associated parties. Verification methods might take many parameters.
A Verification Method class can express different verification methods, such as cryptographic public keys, which can be used to authenticate or authorize interaction with the `controller` or associated parties. Verification methods might take many parameters.
The `domain` property is used to associate a domain with a proof, for use with a `proofPurpose` such as `authentication` and indicating its intended usage.
The challenge property is used to associate a challenge with a proof, for use with a `proofPurpose` such as `authentication`. This string value SHOULD be included in a proof if a `domain` is specified.
The` proofPurpose` property is used to associate a purpose, such as `assertionMethod` or `authentication` with a proof. The proof purpose acts as a safeguard to prevent the proof from being misused by being applied to a purpose other than the one that was intended.
The value of the `proof` property MUST identify `ProofGraph` instances (informally, it indirectly identifies `Proof` instances, each contained in a separate graph). The property is used to associate a proof with a graph of information. The proof property is typically not included in the canonicalized graphs that are then digested and digitally signed. The order of the proofs is not relevant.
The value of the `proofChain` property MUST identify a sequence of `ProofGraph` instances (informally, it indirectly identifies a series of `Proof` instances, each contained in a separate graph). The property is used to provide a sequence of multiple proofs where the order of when the proofs occurred matters. The proof chain property is typically not included in the canonicalized graphs that are then separately digested and digitally signed.
stable
Range:
rdf:List
controller
Controller
A controller is an entity that claims control over a particular resource. Note that control is best validated as a two-way relationship, where the controller claims control over a particular resource, and the resource clearly identifies its controller.
The property's value should be a URL, i.e., not a literal.
A `capabilityDelegation` property is used to express that one or more `verificationMethods` are authorized to verify cryptographic proofs that were created for the purpose of delegating capabilities.
+
The following are property definitions in the sec namespace.
verificationMethod
Verification method
A `verificationMethod` property is used to specify a URL that contains information used for proof verification.
The `domain` property is used to associate a domain with a proof, for use with a `proofPurpose` such as `authentication` and indicating its intended usage.
The challenge property is used to associate a challenge with a proof, for use with a `proofPurpose` such as `authentication`. This string value SHOULD be included in a proof if a `domain` is specified.
The` proofPurpose` property is used to associate a purpose, such as `assertionMethod` or `authentication` with a proof. The proof purpose acts as a safeguard to prevent the proof from being misused by being applied to a purpose other than the one that was intended.
The value of the `proof` property MUST identify `ProofGraph` instances (informally, it indirectly identifies `Proof` instances, each contained in a separate graph). The property is used to associate a proof with a graph of information. The proof property is typically not included in the canonicalized graphs that are then digested and digitally signed. The order of the proofs is not relevant.
The value of the `proofChain` property MUST identify a sequence of `ProofGraph` instances (informally, it indirectly identifies a series of `Proof` instances, each contained in a separate graph). The property is used to provide a sequence of multiple proofs where the order of when the proofs occurred matters. The proof chain property is typically not included in the canonicalized graphs that are then separately digested and digitally signed.
stable
Range:
rdf:List
controller
Controller
A controller is an entity that claims control over a particular resource. Note that control is best validated as a two-way relationship, where the controller claims control over a particular resource, and the resource clearly identifies its controller.
The property's value should be a URL, i.e., not a literal.
A `capabilityDelegation` property is used to express that one or more `verificationMethods` are authorized to verify cryptographic proofs that were created for the purpose of delegating capabilities.
A `verificationMethod` may be referenced by its identifier (a URL) or expressed in full.
-
The aforementioned proofs are created to prove that some entity is delegating the authority to take some action to another entity. A verifier of the proof should expect the proof to express a `proofPurpose` of `capabilityDelegation` and reference a `verificationMethod` to verify it. The dereferenced `verificationMethod` MUST have a controller property that has a property of `capabilityDelegation` that references the `verificationMethod`. This indicates that the controller has authorized it for the expressed `proofPurpose`.
A `capabilityInvocation` property is used to express that one or more `verificationMethods` are authorized to verify cryptographic proofs that were created for the purpose of invoking capabilities.
+
The aforementioned proofs are created to prove that some entity is delegating the authority to take some action to another entity. A verifier of the proof should expect the proof to express a `proofPurpose` of `capabilityDelegation` and reference a `verificationMethod` to verify it. The dereferenced `verificationMethod` MUST have a controller property that has a property of `capabilityDelegation` that references the `verificationMethod`. This indicates that the controller has authorized it for the expressed `proofPurpose`.
A `capabilityInvocation` property is used to express that one or more `verificationMethods` are authorized to verify cryptographic proofs that were created for the purpose of invoking capabilities.
A `verificationMethod` MAY be referenced by its identifier (a URL) or expressed in full.
-
The aforementioned proofs are created to prove that some entity is attempting to exercise some authority they possess to take an action. A verifier of the proof should expect the proof to express a `proofPurpose` of `capabilityInvocation` and reference a `verificationMethod` to verify it. The dereferenced `verificationMethod` MUST have a controller property that, when dereferenced, has a property of `capabilityInvocation` that references the `verificationMethod.` This indicates that the controller has authorized it for the expressed `proofPurpose`.
Indicates that a proof is used for for key agreement protocols, such as Elliptic Curve Diffie Hellman key agreement used by popular encryption libraries.
The public key multibase property is used to specify the multibase-encoded version of a public key. The contents of the property are defined by specifications such as ED25519-2020 and listed in the Linked Data Cryptosuite Registry. Most public key type definitions are expected to:
+
The aforementioned proofs are created to prove that some entity is attempting to exercise some authority they possess to take an action. A verifier of the proof should expect the proof to express a `proofPurpose` of `capabilityInvocation` and reference a `verificationMethod` to verify it. The dereferenced `verificationMethod` MUST have a controller property that, when dereferenced, has a property of `capabilityInvocation` that references the `verificationMethod.` This indicates that the controller has authorized it for the expressed `proofPurpose`.
Indicates that a proof is used for for key agreement protocols, such as Elliptic Curve Diffie Hellman key agreement used by popular encryption libraries.
The public key multibase property is used to specify the multibase-encoded version of a public key. The contents of the property are defined by specifications such as ED25519-2020 and listed in the Linked Data Cryptosuite Registry. Most public key type definitions are expected to:
Specify only a single encoding base per public key type as it reduces implementation burden and increases the chances of reaching broad interoperability.
Specify a multicodec header on the encoded public key to aid encoding and decoding applications in confirming that they are serializing and deserializing an expected public key type.
Use compressed binary formats to ensure efficient key sizes.
-
All terms in this section are unstable, and should be used with care.
- After further experimentation and usage experience they may become stable in later versions of this specification, but they may also become fully deprecated.
+
All terms in this section are
+ reserved.
+ Implementers may use these terms, but should expect them and/or their meanings to change during the process to normatively specify them.
+ Implementers should not use these properties without a publicly disclosed specification describing their implementation.
-
-
Unstable classes
-
The following are unstable class definitions in the sec namespace:
ProofGraph
An RDF Graph for a digital proof (unstable)
Instances of this class are RDF Graphs, where each of these graphs must include exactly one Proof.
This class represents a digital signature on serialized data. It is an abstract class and should not be used other than for Semantic Web reasoning purposes, such as by a reasoning agent. This class MUST NOT be used directly, but only through its subclasses.
This class represents a message digest that may be used for data integrity verification. The digest algorithm used will determine the cryptographic properties of the digest.
deprecatedtrue
EncryptedMessage
Encrypted message (deprecated)
A class of messages that are obfuscated in some cryptographic manner. These messages are incredibly difficult to decrypt without the proper decryption key.
A graph signature is used for digital signatures on RDF graphs. The default canonicalization mechanism is specified in the RDF Graph normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and RSA to perform the digital signature.
Linked data signature, 2015 version (was deprecated in the CCG document) (deprecated)
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and RSA to perform the digital signature.
Linked data signature, 2016 version (was deprecated in the CCG document) (deprecated)
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and RSA to perform the digital signature.
Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and ECDSA to perform the digital signature.
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and JWS to perform the digital signature.
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which deterministically names all unnamed nodes. Importantly, a `BbsBlsSignature` digests each of the statements produced by the normalization process individually to enable selective disclosure. The signature mechanism uses Blake2B as the digest for each statement and produces a single output digital signature.
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which deterministically names all unnamed nodes. Importantly, a `BbsBlsSignatureProof2020` is in fact a proof of knowledge of an unrevealed BbsBlsSignature2020 enabling the ability to selectively reveal information from the set that was originally signed. Each of the statements produced by the normalizing process for a JSON-LD document featuring a `BbsBlsSignatureProof2020` represent statements that were originally signed in producing the `BbsBlsSignature2020` and represent the denomination under which information can be selectively disclosed. The signature mechanism uses Blake2B as the digest for each statement and produces a single output digital signature.
This class represents a digital signature on serialized data. It is an abstract class and should not be used other than for Semantic Web reasoning purposes, such as by a reasoning agent. This class MUST NOT be used directly, but only through its subclasses.
This class represents a message digest that may be used for data integrity verification. The digest algorithm used will determine the cryptographic properties of the digest.
deprecatedtrue
EncryptedMessage
Encrypted message (deprecated)
A class of messages that are obfuscated in some cryptographic manner. These messages are incredibly difficult to decrypt without the proper decryption key.
A graph signature is used for digital signatures on RDF graphs. The default canonicalization mechanism is specified in the RDF Graph normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and RSA to perform the digital signature.
Linked data signature, 2015 version (was deprecated in the CCG document) (deprecated)
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and RSA to perform the digital signature.
Linked data signature, 2016 version (was deprecated in the CCG document) (deprecated)
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and RSA to perform the digital signature.
Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which effectively deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and ECDSA to perform the digital signature.
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which deterministically names all unnamed nodes. The default signature mechanism uses a SHA-256 digest and JWS to perform the digital signature.
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which deterministically names all unnamed nodes. Importantly, a `BbsBlsSignature` digests each of the statements produced by the normalization process individually to enable selective disclosure. The signature mechanism uses Blake2B as the digest for each statement and produces a single output digital signature.
A Linked Data signature is used for digital signatures on RDF Datasets. The default canonicalization mechanism is specified in the RDF Dataset Normalization specification, which deterministically names all unnamed nodes. Importantly, a `BbsBlsSignatureProof2020` is in fact a proof of knowledge of an unrevealed BbsBlsSignature2020 enabling the ability to selectively reveal information from the set that was originally signed. Each of the statements produced by the normalizing process for a JSON-LD document featuring a `BbsBlsSignatureProof2020` represent statements that were originally signed in producing the `BbsBlsSignature2020` and represent the denomination under which information can be selectively disclosed. The signature mechanism uses Blake2B as the digest for each statement and produces a single output digital signature.
The following are deprecated property definitions in the sec namespace:
cipherAlgorithm
Cipher algorithm (deprecated)
The cipher algorithm describes the mechanism used to encrypt a message. It is typically a string expressing the cipher suite, the strength of the cipher, and a block cipher mode.
The digest algorithm is used to specify the cryptographic function to use when generating the data to be digitally signed. Typically, data that is to be signed goes through three steps: 1) canonicalization, 2) digest, and 3) signature. This property is used to specify the algorithm that should be used for step 2. A signature class typically specifies a default digest method, so this property is typically used to specify information for a signature algorithm.
deprecatedtrue
Range:
xsd:string
digestValue
Digest value (deprecated)
The digest value is used to express the output of the digest algorithm expressed in Base-16 (hexadecimal) format.
deprecatedtrue
Range:
xsd:string
blockchainAccountId
Blockchain account ID (deprecated)
A `blockchainAccountId` property is used to specify a blockchain account identifier, as per the CAIP-10Account ID Specification.
deprecatedtrue
Range:
xsd:string
ethereumAddress
Ethereum address (deprecated)
An `ethereumAddress` property is used to specify the Ethereum address. As per the Ethereum Yellow Paper “Ethereum: a secure decentralised generalised transaction ledger” in consists of a prefix "0x", a common identifier for hexadecimal, concatenated with the rightmost 20 bytes of the Keccak-256 hash (big endian) of the ECDSA public key (the curve used is the so-called secp256k1). In hexadecimal, 2 digits represent a byte, meaning addresses contain 40 hexadecimal digits. The Ethereum address should also contain a checksum as per EIP-55.
The expiration time is typically associated with a `Key` and specifies when the validity of the key will expire.
deprecatedtrue
Range:
xsd:dateTime
initializationVector
Initialization vector (deprecated)
The initialization vector (IV) is a byte stream that is typically used to initialize certain block cipher encryption schemes. For a receiving application to be able to decrypt a message, it must know the decryption key and the initialization vector. The value is typically base-64 encoded.
This property is used in conjunction with the input to the signature hashing function in order to protect against replay attacks. Typically, receivers need to track all nonce values used within a certain time period in order to ensure that an attacker cannot merely re-send a compromised packet in order to execute a privileged request.
The canonicalization algorithm is used to transform the input data into a form that can be passed to a cryptographic digest method. The digest is then digitally signed using a digital signature algorithm. Canonicalization ensures that a piece of software that is generating a digital signature is able to do so on the same set of information in a deterministic manner.
A controller is an entity that claims control over a particular resource. Note that control is best validated as a two-way relationship where the controller claims control over a particular resource, and the resource clearly identifies its controller.
The property's value should be a URL, i.e., not a literal.
deprecatedtrue
owner
Owner (was deprecated in the CCG document) (deprecated)
An owner is an entity that claims control over a particular resource. Note that ownership is best validated as a two-way relationship where the owner claims ownership over a particular resource, and the resource clearly identifies its owner.
The property's value should be a URL, i.e., not a literal.
deprecatedtrue
password
Password (deprecated)
A secret that is used to generate a key that can be used to encrypt or decrypt message. It is typically a string value.
deprecatedtrue
Range:
xsd:string
privateKeyPem
PEM encoded private key (deprecated)
A private key PEM property is used to specify the PEM-encoded version of the private key. This encoding is compatible with almost every Secure Sockets Layer library implementation and typically plugs directly into functions intializing private keys.
A public key PEM property is used to specify the PEM-encoded version of the public key. This encoding is compatible with almost every Secure Sockets Layer library implementation and typically plugs directly into functions initializing public keys.
A `publicKeyHex` property is used to specify the hex-encoded version of the public key, based on section 8 of rfc4648. Hex encoding is also known as Base16 encoding.
The publicKeyService property is used to express the REST URL that provides public key management services.
The property's value should be a URL, i.e., not a literal.
deprecatedtrue
revoked
Revocation time (deprecated)
The revocation time is typically associated with a `Key` that has been marked as invalid as of the date and time associated with the property. Key revocations are often used when a key is compromised, such as the theft of the private key, or during the course of best-practice key rotation schedules.
deprecatedtrue
Range:
xsd:dateTime
jws
Json Web Signature (deprecated)
The jws property is used to associate a detached Json Web Signature with a proof.
The challenge property is used to associate a challenge with a proof, for use with a `proofPurpose` such as `authentication`. This string value SHOULD be included in a proof if a `domain` is specified.
Signature (was deprecated in the CCG document) (deprecated)
The property is used to associate a proof with a graph of information. The proof property is typically not included in the canonicalized graph that is then digested, and digitally signed.
Signature algorithm (was deprecated in the CCG document) (deprecated)
The signature algorithm is used to specify the cryptographic signature function to use when digitally signing the digest data. Typically, text to be signed goes through three steps: 1) canonicalization, 2) digest, and 3) signature. This property is used to specify the algorithm that should be used for step #3. A signature class typically specifies a default signature algorithm, so this property rarely needs to be used in practice when specifying digital signatures.
The property's value should be a URL, i.e., not a literal.
A network address at which a service operates on behalf of a controller. Examples of specific services include discovery services, social networks, file storage services, and verifiable claim repository services. Service endpoints might also be provided by a generalized data interchange protocol, such as extensible data interchange.
The property's value should be a URL, i.e., not a literal.
The x509CertificateChain property is used to associate a chain of X.509 Certificates with a proof. The value of this property is an ordered list where each value in the list is an X.509 Certificate expressed as a DER PKIX format, that is encoded with multibase using the base64pad variant. The certificate directly associated to the verification method used to verify the proof MUST be the first element in the list. Subsequent certificates in the list MAY be included where each one MUST certify the previous one.
The x509CertificateFingerprint property is used to associate an X.509 Certificate with a proof via its fingerprint. The value is a multihash encoded then multibase encoded value using the base64pad variant. It is RECOMMENDED that the fingerprint value be the SHA-256 hash of the X.509 Certificate.
The following are deprecated property definitions in the sec namespace.
cipherAlgorithm
Cipher algorithm (deprecated)
The cipher algorithm describes the mechanism used to encrypt a message. It is typically a string expressing the cipher suite, the strength of the cipher, and a block cipher mode.
The digest algorithm is used to specify the cryptographic function to use when generating the data to be digitally signed. Typically, data that is to be signed goes through three steps: 1) canonicalization, 2) digest, and 3) signature. This property is used to specify the algorithm that should be used for step 2. A signature class typically specifies a default digest method, so this property is typically used to specify information for a signature algorithm.
deprecatedtrue
Range:
xsd:string
digestValue
Digest value (deprecated)
The digest value is used to express the output of the digest algorithm expressed in Base-16 (hexadecimal) format.
deprecatedtrue
Range:
xsd:string
blockchainAccountId
Blockchain account ID (deprecated)
A `blockchainAccountId` property is used to specify a blockchain account identifier, as per the CAIP-10Account ID Specification.
deprecatedtrue
Range:
xsd:string
ethereumAddress
Ethereum address (deprecated)
An `ethereumAddress` property is used to specify the Ethereum address. As per the Ethereum Yellow Paper “Ethereum: a secure decentralised generalised transaction ledger” in consists of a prefix "0x", a common identifier for hexadecimal, concatenated with the rightmost 20 bytes of the Keccak-256 hash (big endian) of the ECDSA public key (the curve used is the so-called secp256k1). In hexadecimal, 2 digits represent a byte, meaning addresses contain 40 hexadecimal digits. The Ethereum address should also contain a checksum as per EIP-55.
The expiration time is typically associated with a `Key` and specifies when the validity of the key will expire.
deprecatedtrue
Range:
xsd:dateTime
initializationVector
Initialization vector (deprecated)
The initialization vector (IV) is a byte stream that is typically used to initialize certain block cipher encryption schemes. For a receiving application to be able to decrypt a message, it must know the decryption key and the initialization vector. The value is typically base-64 encoded.
This property is used in conjunction with the input to the signature hashing function in order to protect against replay attacks. Typically, receivers need to track all nonce values used within a certain time period in order to ensure that an attacker cannot merely re-send a compromised packet in order to execute a privileged request.
The canonicalization algorithm is used to transform the input data into a form that can be passed to a cryptographic digest method. The digest is then digitally signed using a digital signature algorithm. Canonicalization ensures that a piece of software that is generating a digital signature is able to do so on the same set of information in a deterministic manner.
A controller is an entity that claims control over a particular resource. Note that control is best validated as a two-way relationship where the controller claims control over a particular resource, and the resource clearly identifies its controller.
The property's value should be a URL, i.e., not a literal.
deprecatedtrue
owner
Owner (was deprecated in the CCG document) (deprecated)
An owner is an entity that claims control over a particular resource. Note that ownership is best validated as a two-way relationship where the owner claims ownership over a particular resource, and the resource clearly identifies its owner.
The property's value should be a URL, i.e., not a literal.
deprecatedtrue
password
Password (deprecated)
A secret that is used to generate a key that can be used to encrypt or decrypt message. It is typically a string value.
deprecatedtrue
Range:
xsd:string
privateKeyPem
PEM encoded private key (deprecated)
A private key PEM property is used to specify the PEM-encoded version of the private key. This encoding is compatible with almost every Secure Sockets Layer library implementation and typically plugs directly into functions intializing private keys.
A public key PEM property is used to specify the PEM-encoded version of the public key. This encoding is compatible with almost every Secure Sockets Layer library implementation and typically plugs directly into functions initializing public keys.
A `publicKeyHex` property is used to specify the hex-encoded version of the public key, based on section 8 of rfc4648. Hex encoding is also known as Base16 encoding.
The publicKeyService property is used to express the REST URL that provides public key management services.
The property's value should be a URL, i.e., not a literal.
deprecatedtrue
revoked
Revocation time (deprecated)
The revocation time is typically associated with a `Key` that has been marked as invalid as of the date and time associated with the property. Key revocations are often used when a key is compromised, such as the theft of the private key, or during the course of best-practice key rotation schedules.
deprecatedtrue
Range:
xsd:dateTime
jws
Json Web Signature (deprecated)
The jws property is used to associate a detached Json Web Signature with a proof.
The challenge property is used to associate a challenge with a proof, for use with a `proofPurpose` such as `authentication`. This string value SHOULD be included in a proof if a `domain` is specified.
Signature (was deprecated in the CCG document) (deprecated)
The property is used to associate a proof with a graph of information. The proof property is typically not included in the canonicalized graph that is then digested, and digitally signed.
Signature algorithm (was deprecated in the CCG document) (deprecated)
The signature algorithm is used to specify the cryptographic signature function to use when digitally signing the digest data. Typically, text to be signed goes through three steps: 1) canonicalization, 2) digest, and 3) signature. This property is used to specify the algorithm that should be used for step #3. A signature class typically specifies a default signature algorithm, so this property rarely needs to be used in practice when specifying digital signatures.
The property's value should be a URL, i.e., not a literal.
A network address at which a service operates on behalf of a controller. Examples of specific services include discovery services, social networks, file storage services, and verifiable claim repository services. Service endpoints might also be provided by a generalized data interchange protocol, such as extensible data interchange.
The property's value should be a URL, i.e., not a literal.
The x509CertificateChain property is used to associate a chain of X.509 Certificates with a proof. The value of this property is an ordered list where each value in the list is an X.509 Certificate expressed as a DER PKIX format, that is encoded with multibase using the base64pad variant. The certificate directly associated to the verification method used to verify the proof MUST be the first element in the list. Subsequent certificates in the list MAY be included where each one MUST certify the previous one.
The x509CertificateFingerprint property is used to associate an X.509 Certificate with a proof via its fingerprint. The value is a multihash encoded then multibase encoded value using the base64pad variant. It is RECOMMENDED that the fingerprint value be the SHA-256 hash of the X.509 Certificate.
diff --git a/example/test.jsonld b/example/test.jsonld
index e7b47e2..8b0a3ea 100644
--- a/example/test.jsonld
+++ b/example/test.jsonld
@@ -63,18 +63,30 @@
"rdfs_instances": {
"@reverse": "rdfs:isDefinedBy",
"@type": "@id"
+ },
+ "rdfs_datatypes": {
+ "@reverse": "rdfs:isDefinedBy",
+ "@type": "@id"
+ },
+ "dc:title": {
+ "@container": "@language"
+ },
+ "dc:description": {
+ "@container": "@language"
}
},
"@id": "https://w3id.org/security/v1",
"@type": "owl:Ontology",
"dc:title": {
- "en": "Security Vocabulary"
+ "@value": "Security Vocabulary",
+ "@language": "en"
},
"dc:description": {
- "en": "vocabulary used to ensure the authenticity and integrity of Verifiable Credentials and similar types of constrained digital documents using cryptography, especially through the use of digital signatures and related mathematical proofs \n"
+ "@value": "vocabulary used to ensure the authenticity and integrity of Verifiable Credentials and similar types of constrained digital documents using cryptography, especially through the use of digital signatures and related mathematical proofs \n",
+ "@language": "en"
},
"rdfs:seeAlso": "https://www.w3.org/TR/vc-data-integrity/",
- "dc:date": "2023-04-14",
+ "dc:date": "2023-12-13",
"rdfs_classes": [
{
"@id": "sec:Proof",
@@ -94,7 +106,7 @@
"@value": "
Instances of this class are RDF Graphs, where each of these graphs must include exactly one Proof.
A `verificationMethod` property is used to specify a URL that contains information used for proof verification.
"""^^rdf:HTML ;
@@ -326,7 +326,7 @@ sec:verificationMethod a rdfs:Property ;
rdfs:seeAlso ;
.
-sec:domain a rdfs:Property, owl:DatatypeProperty ;
+sec:domain a rdf:Property, owl:DatatypeProperty ;
rdfs:domain sec:Proof ;
rdfs:range xsd:string ;
rdfs:label "Domain of a proof" ;
@@ -335,7 +335,7 @@ sec:domain a rdfs:Property, owl:DatatypeProperty ;
vs:term_status "stable" ;
.
-sec:challenge a rdfs:Property, owl:DatatypeProperty ;
+sec:challenge a rdf:Property, owl:DatatypeProperty ;
rdfs:domain sec:Proof ;
rdfs:range xsd:string ;
rdfs:label "Challenge with a proof" ;
@@ -344,7 +344,7 @@ sec:challenge a rdfs:Property, owl:DatatypeProperty ;
vs:term_status "stable" ;
.
-sec:proofPurpose a rdfs:Property, owl:DatatypeProperty ;
+sec:proofPurpose a rdf:Property, owl:DatatypeProperty ;
rdfs:domain sec:Proof ;
rdfs:range xsd:string ;
rdfs:label "Proof purpose" ;
@@ -353,7 +353,7 @@ sec:proofPurpose a rdfs:Property, owl:DatatypeProperty ;
vs:term_status "stable" ;
.
-sec:proofValue a rdfs:Property, owl:DatatypeProperty ;
+sec:proofValue a rdf:Property, owl:DatatypeProperty ;
rdfs:domain sec:Proof ;
rdfs:range xsd:string ;
rdfs:label "Proof value" ;
@@ -362,7 +362,7 @@ sec:proofValue a rdfs:Property, owl:DatatypeProperty ;
vs:term_status "stable" ;
.
-sec:proof a rdfs:Property ;
+sec:proof a rdf:Property ;
rdfs:range sec:ProofGraph ;
rdfs:label "Proof sets" ;
rdfs:comment """
The value of the `proof` property MUST identify `ProofGraph` instances (informally, it indirectly identifies `Proof` instances, each contained in a separate graph). The property is used to associate a proof with a graph of information. The proof property is typically not included in the canonicalized graphs that are then digested and digitally signed. The order of the proofs is not relevant.
The value of the `proofChain` property MUST identify a sequence of `ProofGraph` instances (informally, it indirectly identifies a series of `Proof` instances, each contained in a separate graph). The property is used to provide a sequence of multiple proofs where the order of when the proofs occurred matters. The proof chain property is typically not included in the canonicalized graphs that are then separately digested and digitally signed.
A controller is an entity that claims control over a particular resource. Note that control is best validated as a two-way relationship, where the controller claims control over a particular resource, and the resource clearly identifies its controller.
A `capabilityDelegation` property is used to express that one or more `verificationMethods` are authorized to verify cryptographic proofs that were created for the purpose of delegating capabilities.
@@ -412,7 +412,7 @@ sec:capabilityDelegation a rdfs:Property ;
vs:term_status "stable" ;
.
-sec:capabilityInvocation a rdfs:Property ;
+sec:capabilityInvocation a rdf:Property ;
rdfs:range VerificationMethod ;
rdfs:label "Capability Invocation Method" ;
rdfs:comment """
A `capabilityInvocation` property is used to express that one or more `verificationMethods` are authorized to verify cryptographic proofs that were created for the purpose of invoking capabilities.
@@ -422,7 +422,7 @@ sec:capabilityInvocation a rdfs:Property ;
vs:term_status "stable" ;
.
-sec:keyAgreement a rdfs:Property ;
+sec:keyAgreement a rdf:Property ;
rdfs:range VerificationMethod ;
rdfs:label "Key agreement protocols" ;
rdfs:comment """
Indicates that a proof is used for for key agreement protocols, such as Elliptic Curve Diffie Hellman key agreement used by popular encryption libraries.