diff --git a/input/images-source/gfi-001.plantuml b/input/images-source/gfi-001.plantuml new file mode 100644 index 0000000..f2ba58d --- /dev/null +++ b/input/images-source/gfi-001.plantuml @@ -0,0 +1,16 @@ +@startuml GFI-001 + +skinparam roundcorner 20 +skinparam defaultFontName Arial +hide footbox +activate issuer + +!pragma teoz true + +participant verifier as "Verifier" +participant issuer as "Issuer/Holder" + +verifier -> issuer: Resolve DID Document Request [GFI-001] +issuer --> verifier: DID Document Response [GFI-001] + +@enduml diff --git a/input/images-source/gfi-003.plantuml b/input/images-source/gfi-003.plantuml new file mode 100644 index 0000000..1812249 --- /dev/null +++ b/input/images-source/gfi-003.plantuml @@ -0,0 +1,16 @@ +@startuml GFI-003 + +skinparam roundcorner 20 +skinparam defaultFontName Arial +hide footbox +activate issuer + +!pragma teoz true + +participant verifier as "Verifier" +participant issuer as "Issuer" + +verifier -> issuer: Revocation Status Information Request [GFI-003] +issuer --> verifier: Revocation Status Information Response [GFI-003] + +@enduml diff --git a/input/images-source/gfi-004.plantuml b/input/images-source/gfi-004.plantuml new file mode 100644 index 0000000..66345ee --- /dev/null +++ b/input/images-source/gfi-004.plantuml @@ -0,0 +1,19 @@ +@startuml GFI-004 + +skinparam roundcorner 20 +skinparam defaultFontName Arial +hide footbox +autoactivate on + +!pragma teoz true + +participant holder as "Holder" +participant verifier as "Verifier" + +holder -> verifier: Nonce Request +verifier --> holder: Nonce Response + +holder -> verifier: Access Token Request +verifier --> holder: Access Token Response + +@enduml diff --git a/input/images-source/gfi-005.plantuml b/input/images-source/gfi-005.plantuml new file mode 100644 index 0000000..dd06e11 --- /dev/null +++ b/input/images-source/gfi-005.plantuml @@ -0,0 +1,18 @@ +@startuml GFI-005 + +skinparam roundcorner 20 +skinparam defaultFontName Arial +hide footbox + +!pragma teoz true + +participant client as "Client" +participant RS as "Resource Server" + +client -> client: Create DPoP Proof +client -> RS: Authenticated API Request +activate RS +RS --> client: Authenticated API Response +deactivate RS + +@enduml diff --git a/input/images-source/gfi-006.plantuml b/input/images-source/gfi-006.plantuml new file mode 100644 index 0000000..3e94515 --- /dev/null +++ b/input/images-source/gfi-006.plantuml @@ -0,0 +1,16 @@ +@startuml GFI-006 + +skinparam roundcorner 20 +skinparam defaultFontName Arial +hide footbox +autoactivate on + +!pragma teoz true + +participant RS as "Resource Server" +participant AS as "Verifier" + +RS -> AS: Introspect Access Token Request +AS --> RS: Introspect Access Token Response + +@enduml diff --git a/input/images/authentication-overview-transactions.png b/input/images/authentication-overview-transactions.png new file mode 100644 index 0000000..f520a82 Binary files /dev/null and b/input/images/authentication-overview-transactions.png differ diff --git a/input/pagecontent/GFI-001.md b/input/pagecontent/GFI-001.md new file mode 100644 index 0000000..de12c1b --- /dev/null +++ b/input/pagecontent/GFI-001.md @@ -0,0 +1,97 @@ +### Scope + +The Request key material transaction returns a document containing the public key material for a given entity. + +### Actor Roles + +| Actor | Role | +| ------------- | ---------------------------------------------------------------------------------- | +| Verifier | Requests key material for a given entity based on a Decentralized Identifier (DID) | +| Issuer/Holder | Responds to the request with the public key material associated with the DID | + +### Referenced standards + +- [DID Core](https://www.w3.org/TR/did-core/) +- [DID Resolution](https://www.w3.org/TR/did-resolution/) +- [DID Web Method](https://w3c-ccg.github.io/did-method-web/) + +### Messages + +1. Resolve DID Document Request +2. DID Document Response + +
+{% include GFI-001.svg %} +
+ +#### Resolve DID Document Request + +##### Trigger events + +A verifier needs to verify the authenticity of a signature on a verifiable credential or presentation. + +##### Message semantics + +A verifier initiates a resolve DID document request using a HTTP GET request to the DID web url. No further parameters are required. +The DID web url is constructed following the rules as defined in the [DID Web Method](https://w3c-ccg.github.io/did-method-web/). + +##### Example + +Example did:web + +``` +did:web:example.com:user:alice +``` + +Which resolves to the DID document at: + +``` +GET https://example.com/user/alice/did.json +``` + +#### DID Document Response + +##### Trigger events + +The requested party responds to the resolve DID document request. + +##### Message semantics + +The requested party responds with a HTTP 200 OK response containing the DID document in the body of the response. The DID document is a JSON-LD document conforming to the [DID Core](https://www.w3.org/TR/did-core/) specification. + +##### Example + +```json +{ + "@context": "https://www.w3.org/ns/did/v1", + "id": "did:web:example.com:user:alice", + "verificationMethod": [ + { + "id": "did:web:example.com:user:alice#key-1", + "type": "JsonWebKey2020", + "controller": "did:web:example.com:user:alice", + "publicKeyJwk": { + "kty": "EC", + "crv": "P-256", + "x": "...", + "y": "..." + } + } + ], + "authentication": ["did:web:example.com:user:alice#key-1"] +} +``` + +##### Expected actions + +**Case 1**: The DID document is found on the server. + +`HTTP 200` (OK) is returned as the HTTP status code. + +A DID document is returned in the body of the response. + +**Case 2**: The DID document is not found on the server. + +`HTTP 404` (Not Found) is returned as the HTTP status code. + +No body is returned in the response. diff --git a/input/pagecontent/GFI-002.md b/input/pagecontent/GFI-002.md new file mode 100644 index 0000000..e666f80 --- /dev/null +++ b/input/pagecontent/GFI-002.md @@ -0,0 +1,26 @@ +### Scope + +The Issue Claims transaction describes the process of issuing verifiable claims from an authoritative issuer to a holder. The claims are typically encapsulated within a verifiable credential, which the holder can later present to verifiers as proof of certain attributes or qualifications. +The Issue Claims transaction can be initiated by the holder or the issuer, depending on the use case and the relationship between the parties involved. + +#### Optionality + +This transaction is optional and provides a standardized way requesting and transferring verifiable claims between an issuer and a holder. It is possible to request, issue and transfer these claims using other protocols such as email or other messaging systems. + +### Actor Roles + +| Actor | Role | +| ------ | --------------------------------------------------------------------------- | +| Issuer | Issues verifiable claims to a holder in the form of a verifiable credential | +| Holder | Receives verifiable claims from the issuer and stores them securely | + +### Referenced standards + +- [Verifiable Credentials Data Model 1.0](https://www.w3.org/TR/vc-data-model/) +- [OpenID4VCI](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) + +### Messages + +1. Credential Offer +2. Credential Request +3. Credential Response diff --git a/input/pagecontent/GFI-003.md b/input/pagecontent/GFI-003.md new file mode 100644 index 0000000..9357920 --- /dev/null +++ b/input/pagecontent/GFI-003.md @@ -0,0 +1,129 @@ +### Scope + +The transaction Request Revocation Status is used by a verifier to determine the revocation status of a verifiable credential presented by a holder. The verifier sends a request to the revocation registry or authority specified in the credential to determine if the credential is still valid or has been revoked. + +### Actor Roles + +| Actor | Role | +| -------- | -------------------------------------------------------------------------------------- | +| Verifier | Requests the revocation information of a verifiable credential | +| Issuer | Provides the revocation information which the verifier can use to determine the status | + +### Referenced standards + +- [Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model/) +- [Bitstring Status List v1.0](https://www.w3.org/TR/vc-bitstring-status-list/) + +### Messages + +1. Revocation Status Information Request +1. Revocation Status Information Response + +
+{% include GFI-003.svg %} +
+ +#### Revocation Status Information Request + +##### Trigger events + +- A Holder presents a verifiable credential to a verifier and the verifier needs to check the revocation status of the credential. +- A timer based event to refresh the revocation status information based on the `ValidUntil` field in the status list credential. + +##### Message semantics + +The verifier initiates a revocation status information request using a HTTP GET request to the revocation URL specified in the verifiable credential under the `credentialStatus` property. Such as specified in the [Bitstring Status List v1.0](https://www.w3.org/TR/vc-bitstring-status-list/) specification. + +##### Example + +Note: these examples are non normative, for implementation the actual specifications should be followed. + +Example of a revocable Verifiable Credential: + +```json +{ + "@context": [ + "https://www.w3.org/2018/credentials/v1", + "https://www.w3.org/2018/credentials/examples/v1", + "https://w3id.org/vc/status-list/2021/v1" + ], + "id": "http://example.edu/credentials/3732", + "type": ["VerifiableCredential", "UniversityDegreeCredential"], + "issuer": "https://example.edu/issuers/14", + "issuanceDate": "2020-03-10T04:24:12.164Z", + "credentialSubject": { + "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", + "degree": { + "type": "BachelorDegree", + "name": "Bachelor of Science and Arts" + } + }, + "credentialStatus": { + "id": "https://example.edu/status/24#94567", + "type": "BitstringStatusListEntry", + "statusPurpose": "revocation", + "statusListIndex": "94567", + "statusListCredential": "https://example.edu/status/24" + }, + "proof": { + "type": "RsaSignature2018", + "created": "2020-03-10T04:24:12Z", + "proofPurpose": "assertionMethod", + "verificationMethod": "https://example.edu/issuers/keys/1", + "jws": "..." + } +} +``` + +This results in the following request: + +``` +GET https://example.edu/status/24 +``` + +#### Revocation Status Information Response + +##### Trigger events + +The requested party responds to the revocation status information request. + +##### Message semantics + +The Issuer should respond with the latest version of the status list credential, signed with the Issuer's proofing method. + +##### Example + +Note: these examples are non normative, for implementation the actual specifications should be followed. + +Example of a Status List Credential response: + +```json +{ + "@context": [ + "https://www.w3.org/2018/credentials/v1", + "https://w3id.org/vc/status-list/2021/v1" + ], + "id": "https://example.edu/status/24", + "type": ["VerifiableCredential", "StatusList2021Credential"], + "issuer": "https://example.edu/issuers/14", + "validFrom": "2025-03-10T04:24:12Z", + "ValidUntil": "2025-03-10T08:24:12Z", + "credentialSubject": { + "id": "https://example.edu/status/24#list", + "type": "BitstringStatusList", + "statusPurpose": "revocation", + "encodedList": "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAPgG6AAB" + }, + "proof": { + "type": "RsaSignature2018", + "created": "2020-03-10T04:24:12Z", + "proofPurpose": "assertionMethod", + "verificationMethod": "https://example.edu/issuers/keys/1", + "jws": "..." + } +} +``` + +##### Expected actions + +The verifier processes the status list credential as specified by the [Validate Algorithm section of the specification](https://www.w3.org/TR/vc-bitstring-status-list/#validate-algorithm) to determine the revocation status of the verifiable credential presented by the holder. The verifier decodes the `encodedList` field to obtain the bitstring representing the revocation status of credentials. The verifier checks the bit at the index specified in the `statusListIndex` field of the verifiable credential's `credentialStatus` property. If the bit is set to `1`, the credential is revoked; if it is set to `0`, the credential is valid. diff --git a/input/pagecontent/GFI-004.md b/input/pagecontent/GFI-004.md new file mode 100644 index 0000000..6232418 --- /dev/null +++ b/input/pagecontent/GFI-004.md @@ -0,0 +1,201 @@ +### Scope + +The transaction Request Access Token is used by a client to obtain an access token from an authorization server. The client offers credentials from an holder to the authorization server which then verifies the credentials and answers with an access token that can be used to access a protected resource. + +In order to proof possession of the credentials, the holder uses its private key to sign a challenge provided by the verifier in the form of a nonce. + +This interaction is scoped on the interaction between two computers with not necessarily a human in the loop. Therefore the interaction is a back-channel interaction without a user-agent such as a web browser. For this reason the OAuth 2.0 Extension [RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523) is used to offer the credentials in the form of a JWT assertion directly to the token endpoint without the use of a authorization request. + +### Actor Roles + +| Actor | Role | +| ------------------------------- | ----------------------------------------------------------------------------------------- | +| Holder (Client) | Requests an access token from the authorization server by offering verifiable credentials | +| Verifier (Authorization Server) | Verifies the offered credentials and issues an access token | + +### Referenced standards + +- [OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749) +- [RFC 7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants](https://datatracker.ietf.org/doc/html/rfc7523) +- [Verifiable Credentials Data Model 1.1](https://www.w3.org/TR/2022/REC-vc-data-model-20220303/) +- [OAuth 2.0 Demonstration of Proof-of-Possession (DPoP)](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-04) + +### Messages + +1. Nonce Request +2. Nonce Response +3. Access Token Request +4. Access Token Response + +
+{% include GFI-004.svg %} +
+ +#### Nonce Request + +##### Trigger events + +- A client needs to obtain an access token from an authorization server and needs a nonce to include in the access token request. + +##### Message semantics + +The client initiates a nonce request using a HTTP POST request to the authorization server's nonce endpoint. No further parameters are required. + +##### Example + +Below is a non-normative example of a Nonce Request: + +``` +POST /nonce HTTP/1.1 +Host: example.com +Content-Length: 0 +``` + +#### Nonce Response + +##### Trigger events + +- The authorization server responds to the nonce request with a nonce that the client can use in the access token request. + +##### Message semantics + +The authorization server responds with a HTTP 200 OK response containing the nonce in the body of the response. The nonce is a random value that is used to prevent replay attacks. + +The nonce must be an opaque and non predictable value. Authorization server should implement a mechanism to ensure the nonce is only used once and has a limited lifetime. + +Due to the temporal nature of the nonce, the response should include a `Cache-Control: no-store` header to prevent caching of the nonce. + +##### Example + +Below is a non-normative example of a Nonce Response: + +``` +HTTP/1.1 200 OK +Content-Type: application/json +Cache-Control: no-store +{ + "nonce": "n-0S6_WzA2Mj" +} +``` + +##### Expected Actions + +- The client extracts the nonce from the response and includes it in the access token request. +- The authorization server stores the nonce and ensures it is only used once and has a limited lifetime. + +#### Access Token Request + +##### Trigger events + +- A client needs to obtain an access token from an authorization server and has obtained a nonce from the authorization server. + +##### Message semantics + +The client requests an access token from the authorization server using the OAuth 2.0 JWT bearer token flow as defined in [RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523). + +If an authorization server is shared between multiple (care) organizations (e.t. a multi-tenant setup), the authentication server must have a path parameter or a different endpoint to identify the organization the client is requesting the access token for. The client should not have to know the internal identifier of the organization. The access token must be bound to the requested organization. + +If the client wants to bind the access token to a private key, it can include a DPoP header in the request as defined in [OAuth 2.0 Demonstration of Proof-of-Possession (DPoP)](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-04). + +Verifiable Credentials and Verifiable Presentations must be encoded as JWTs as defined in [Section 6.3.1 of the Verifiable Credentials Data Model 1.1](https://www.w3.org/TR/2022/REC-vc-data-model-20220303/#json-web-token). + +###### Request parameters + +The request must include the following information: + +- `grant_type`: Must be set to `urn:ietf:params:oauth:grant-type:jwt-bearer` +- `assertion`: A JWT assertion in the form of a verifiable presentation containing the verifiable credentials offered by the holder. The JWT must be signed by the holder and the proof must contain the nonce obtained from the authorization server. +- client_assertion: A JWT signed by the client to authenticate itself to the authorization server. The JWT is in the form of a Verifiable Presentation containing a verifiable credentials which contain the identifier of the client and its certifications/affiliations which authorizes the client to request the scopes it is requesting. Just like the `assertion` the `client_assertion` must also contain the nonce obtained from the authorization server to proof the ownership of the credentials. +- `scope`: (Optional) A space-separated list of scopes that the client is requesting. + +###### Assertions + +The **assertion** and the **client_assertion** must include the following properties: + +- `iss`: The issuer of the JWT. For the `assertion` this is the identifier of the holder. For the `client_assertion` this is the identifier of the client. +- `aud`: The audience of the JWT. This must be the identifier of the authorization server. +- `jti`: A unique identifier for the JWT. +- `nbf`: (Optional) The time before which the JWT must not be accepted for processing. +- `iat`: The time at which the JWT was issued. +- `exp`: The expiration time on or after which the JWT must not be accepted for processing. +- `nonce`: The nonce obtained from the authorization server. +- `vp`: The verifiable presentation containing the verifiable credentials. The `vp` claim must conform to the [Verifiable Credentials Data Model 1.0](https://www.w3.org/TR/vc-data-model/) specification. + +The request must be sent as a HTTP POST request to the authorization server's token endpoint with the `Content-Type` header set to `application/x-www-form-urlencoded`. + +##### Example + +Below is a non-normative example of an Access Token Request: + +``` +POST /oauth/{tenant-id}/token HTTP/1.1 +Host: example.com +Content-Type: application/x-www-form-urlencoded +grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer& +assertion=eyJhbGciOiJFUzI1NiIsInR5c& +client-assertion-type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer& +client_assertion=eyJhbGciOiJFUzI1NiIsInR5c& +scope=use-case1 use-case2 +``` + +Below is a non-normative example of a JWT assertion in the form of a verifiable presentation: + +```json +{ + "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21", + "jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5", + "aud": "did:example:4a57546973436f6f6c4a4a57573", + "nbf": 1541493724, + "iat": 1541493724, + "exp": 1573029723, + "nonce": "n-0S6_WzA2Mj", + "vp": { + "@context": [ + "https://www.w3.org/2018/credentials/v1", + "https://www.w3.org/2018/credentials/examples/v1" + ], + "type": ["VerifiablePresentation"], + "verifiableCredential": ["... verifiable credential ..."] + } +} +``` + +#### Access Token Response + +##### Trigger events + +- The authorization server responds to the access token request with an access token that the client can use to access a protected resource. + +##### Message semantics + +The verifier responds with a HTTP 200 OK response containing the access token in the body of the response. + +The access token is opaque to the client and the format is determined by the authorization server. + +If the client provided a DPoP header in the access token request, the authorization server must issue a DPoP-bound access token. + +The response must include the following information: + +- `access_token`: The access token issued by the authorization server. +- `token_type`: The type of the token issued. Must be set to `Bearer` or `DPoP`. +- `expires_in`: (Optional) The lifetime in seconds of the access token. +- `scope`: (Optional) The scope of the access token. + +##### Example + +Below is a non-normative example of an Access Token Response: + +``` +HTTP/1.1 200 OK +Content-Type: application/json +{ + "access_token": "SlAV32hkKG", + "token_type": "Bearer", + "expires_in": 3600, + "scope": "use-case1 use-case2" +} +``` + +##### Expected Actions + +- The client extracts the access token from the response and uses it to access the protected resource. diff --git a/input/pagecontent/GFI-005.md b/input/pagecontent/GFI-005.md new file mode 100644 index 0000000..8a1aa57 --- /dev/null +++ b/input/pagecontent/GFI-005.md @@ -0,0 +1,103 @@ +### Scope + +The transaction Authenticated Interaction describes a secure and authenticated communication channel between two parties, typically a client representing a holder and a data custodian protected by the verifier. This channel is created on the application layer using a token based authentication mechanism. + +This interaction describes how a client can use the access token in an HTTP request to interact with a RESTful API provided by a resource server at the Custodian. To prevent token theft and replay attacks, the client uses the OAuth 2.0 Demonstration of Proof-of-Possession (DPoP) mechanism to bind the access token to a public/private key pair held by the client. + +### Actor Roles + +| Actor | Role | +| --------- | ----------------------------------------------------------------------------------------------------- | +| Holder | Uses an access token to interact with a resource server at the custodian | +| Custodian | Provides a RESTful API to access and manage data, protected by an access token issued by the verifier | + +### Referenced standards + +- [OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749) +- [OAuth 2.0 Demonstration of Proof-of-Possession (DPoP)](https://datatracker.ietf.org/doc/html/rfc9449) + +### Messages + +1. Create DPoP Proof +2. Authenticated API Request +3. Authenticated API Response + +
+{% include GFI-005.svg %} +
+ +#### Create DPoP Proof + +##### Trigger events + +- A client needs to access or manage data at a custodian using a RESTful API and has obtained an access token from a verifier. + +##### Message semantics + +The client creates a DPoP proof JWT as specified in the [OAuth 2.0 Demonstration of Proof-of-Possession (DPoP)](https://datatracker.ietf.org/doc/html/rfc9449) specification. The DPoP proof JWT includes claims such as `htm` (HTTP method), `htu` (HTTP URI), `jti` (JWT ID), and `iat` (issued at time). + +##### Example + +Below is a non-normative example of a DPoP proof JWT: + +Header: + +```json +{ + "typ": "dpop+jwt", + "alg": "RS256", + "jwk": { + "kty": "RSA", + "e": "AQAB", + "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4cbbfAAtVT86..." + } +} +``` + +Payload: + +```json +{ + "htm": "GET", + "htu": "https://custodian.example.com/fhir/Patient/123", + "jti": "a-123", + "iat": 1618884473 +} +``` + +#### Authenticated API Request + +##### Trigger events + +- A client needs to access or manage data at a custodian using a RESTful API and has obtained an access token from a verifier. + +##### Message semantics + +The client creates a DPoP proof JWT as specified in the [OAuth 2.0 Demonstration of Proof-of-Possession (DPoP)](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-04) specification. The DPoP proof JWT includes claims such as `htm` (HTTP method), `htu` (HTTP URI), `jti` (JWT ID), and `iat` (issued at time). + +The Access Token must be included in the `Authorization` header as a DPoP token, and the DPoP proof JWT must be included in the `DPoP` header of the HTTP request. + +##### Example + +Below is a non-normative example of an Authenticated API Request: + +``` +GET /fhir/Patient/123 HTTP/1.1 +Host: custodian.example.com +Authorization: DPoP eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... +DPoP: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... +``` + +#### Authenticated API Response + +##### Trigger events + +- The custodian processes the authenticated API request and responds with the requested data or an appropriate status + +##### Message semantics + +The resource server verifies the DPoP proof and the access token included in the request. If the verification is successful and the access token is valid, the custodian processes the request accordingly and responds with the requested data or a status message. + +##### Expected Actions + +The resource server should store the `jti` claim from the DPoP proof until it expires, to prevent replay attacks. diff --git a/input/pagecontent/GFI-006.md b/input/pagecontent/GFI-006.md new file mode 100644 index 0000000..7b8b192 --- /dev/null +++ b/input/pagecontent/GFI-006.md @@ -0,0 +1,164 @@ +### Scope + +The transaction Introspect Access Token allows a resource server (Custodian) to validate and obtain metadata about an access token issued by an authorization server (Verifier). + +The introspection returns the active state of the token along with additional the identity claims associated with the token. This information can be used by the resource server down stream during the authorization decision. + +The introspection transaction is added so the access token format can be opaque to the resource server. This allows the authorization server to use any token format, including self-contained tokens such as JWTs, without requiring the resource server to understand the token format. + +In case the access token is a self-contained token such as a JWT, the resource server can validate the token locally without needing to call the introspection endpoint. However, the resource server needs to be able to validate the token signature and parse the token claims which adds complexity and duplicates logic that is already present in the authorization server. + +### Actor Roles + +| Actor | Role | +| --------- | ----------------------------------------------------------------------------------------------- | +| Custodian | Validates the access token and retrieves metadata about the token from the authorization server | +| Verifier | Provides an introspection endpoint to validate access tokens and return associated metadata | + +### Referenced standards + +- [OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749) +- [OAuth 2.0 Token Introspection](https://datatracker.ietf.org/doc/html/rfc7662) +- [OAuth 2.0 Demonstration of Proof-of-Possession (DPoP)](https://datatracker.ietf.org/doc/html/rfc9449) + +### Messages + +1. Introspect Access Token Request +2. Introspect Access Token Response + +
+{% include GFI-006.svg %} +
+ +#### Introspect Access Token Request + +##### Trigger events + +- A resource server (Custodian) needs to validate an access token presented by a client (Holder) and obtain metadata about the token and identity claims of the holder. + +##### Message semantics + +The resource server initiates an introspect access token request using a HTTP POST request to the authorization server's introspection endpoint. The request includes the access token to be introspected. + +##### Example + +Below is a non-normative example of an Introspect Access Token Request: + +``` +POST /introspect HTTP/1.1 +Host: example.com +Content-Type: application/x-www-form-urlencoded + +token=Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU +``` + +#### Introspect Access Token Response + +##### Trigger events + +- The authorization server responds to the introspect access token request with the active state of the token and associated metadata. + +##### Message semantics + +The authorization server responds with a HTTP 200 OK response containing a JSON object in the body of the response. The JSON object includes an `active` boolean field indicating whether the token is valid. + +The `iss` must be the decentralized identifier (DID) of the authorization server. +The `aud` must be the decentralized identifier (DID) of the custodian. + +For a DPoP bound access token, the response also includes a `cnf` claim containing the public key information that can be used to verify the DPoP proof presented by the client as defined in [Section 6.2 of RFC 9449](https://datatracker.ietf.org/doc/html/rfc9449#section-6.2). + +The response may also include the identity claims associated with the token in the `assertions` a `client_assertions` properties. Claims are grouped by subject and each claim has an array of objects with the metadata of the claim, such as the issuer, validity period and the actual claim value. + +##### Example + +Below is a non-normative example of an Introspect Access Token Response: + +``` +HTTP/1.1 200 OK +Content-Type: application/json +Cache-Control: no-store +Pragma: no-cache +{ + "active": true, + "scope": "read write", + "token_type": "DPoP", + "exp": 1419356238, + "iat": 1419350238, + "nbf": 1419350238, + "aud": "did:web:custodian.example.com", + "iss": "did:web:verifier.example.com", + "jti": "123e4567-e89b-12d3-a456-426614174000", + "cnf": { + "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" + }, + "assertions": { + "did:web:example.com:users:john": { + "name": [{ + "value": "John Doe", + "iss": "https://issuer.example.com", + "iat": 1618884473, + "exp": 1672531199 + }], + "email": [{ + "value": "john@example.com", + "iss": "https://issuer.example.com", + "iat": 1618884473, + "exp": 1672531199 + },{ + "value": "john.doe@other.example.com", + "iss": "https://other-issuer.example.com", + "iat": 1618884473, + "exp": 1672531199 + }] + }, + "did:web:org.example.com": { + "identifier": [{ + "value": { + "type": "Organization", + "name": "Example Org", + "registrationNumber": "123456789" + }, + "iss": "https://issuer.example.com", + "iat": 1618884473, + "exp": 1672531199 + }] + } + }, + "client_assertions": { + "did:web:example.com:apps:myapp": { + "app_id": [{ + "value": "myapp", + "iss": "https://auth.example.com", + "iat": 1618884473, + "exp": 1672531199 + }], + "certification": [{ + "value": "UseCase1,UseCase2", + "iss": "https://auth.example.com", + "iat": 1618884473, + "exp": 1672531199 + }] + } + } +} +``` + +##### Expected actions + +###### Response Handling + +**Case 1**: The access token is valid. +`HTTP 200` (OK) is returned as the HTTP status code. +The response body contains a JSON object with the `active` field set to `true` and additional metadata about the token and identity claims. + +**Case 2**: The access token is invalid or expired. +`HTTP 200` (OK) is returned as the HTTP status code. +The response body contains a JSON object with the `active` field set to `false`. Other +fields may be omitted or set to `null`. +**Case 3**: The introspection request is malformed or missing required parameters. +`HTTP 400` (Bad Request) is returned as the HTTP status code. +The response body contains an error message indicating the issue with the request. + +###### DPoP Proof Validation + +The authorization server does not check the validity of the DPoP proof. The resource server must validate the DPoP proof separately by checking the `cnf.jkt` claim in the introspection response against the DPoP proof presented by the client. This claim contains the JWK thumbprint of the public key used to sign the DPoP proof. The resource server must ensure that the `jkt` value matches the thumbprint of the public key in the DPoP proof to confirm that the client possesses the private key corresponding to the public key. diff --git a/input/pagecontent/authentication.md b/input/pagecontent/authentication.md index e69de29..8b2d329 100644 --- a/input/pagecontent/authentication.md +++ b/input/pagecontent/authentication.md @@ -0,0 +1,279 @@ +### Introduction + +Authentication is the process of verifying the identity of an entity. In the context of healthcare, authentication is used to verify the identity of healthcare professionals and care organizations. This is important to ensure that only authorized entities can access sensitive information and resources. + +The verified identity is often used downstream for authorization and accounting. Authorization is the process of granting access to resources based on the identity of an entity. Accounting is the process of tracking the actions of an entity. + +#### Requirements + +There exists a multitude of authentication solutions, therefore it is important to define the requirements for authentication in the context of healthcare. The requirements are: + +- Work with identity claims from the authoritative sources +- Support combinations of identity claims from different trusted issuers +- Support for use-cases with and without an end-user (healthcare professional) +- Support for authorizing vendors to act on behalf of a (care) organization +- Support for limiting the scope of a vendor's authorization +- Support for authorizing (care) organizations to act on behalf of a healthcare professional +- User-friendly solution for healthcare professionals +- Cost-efficient solution for care organizations +- Flexible solution that can be adapted to different use-cases +- Peer-2-peer trust which allows direct interactions between the involved parties without involvement of a third party +- No single point of failure +- Privacy by design +- Security by design +- Support for leveraging existing identity solutions + +#### Terminology + +Throughout this document the following terminology is used: + +- Entity: An actor in the system (person or organization) +- Agent: A digital representation of an entity that acts on its behalf, also often called an identity wallet +- Vendor: A party that offers Agents to its customers (care organizations and healthcare professionals) +- Identity: A set of claims about an entity (person or organization) which is relevant in a specific context +- Verifiable Identifier (VID): An identifier that can be (cryptographically) verified +- Claim: A statement about an entity (e.g. name, role, affiliation) +- Verifiable Claim: A claim that can be cryptographically verified +- Issuer: An entity that issues claims about another entity +- Authoritative source: An issuer that is trusted to issue claims about a specific entity +- Verifier: An entity that verifies the identity of another entity based on its claims +- Holder: An entity that holds claims about itself or is authorized to present claims about another entity +- Authentication: The process of verifying the identity of an entity +- Authorization: The process of granting access to resources based on the identity of an entity +- Use-case: A specific scenario in which authentication and authorization are required + +#### Problem overview + +A typical scenario in healthcare is that a healthcare professional needs to access a resource (e.g. patient data) which is located at a different organization (e.g. a hospital). +In the Netherlands, the custodian of the patient data is by law forbidden to share the data with third parties. Several exceptions to that rule exists. One responsibility of the custodian is to ensure that the requesting party is authorized to access the data. In order to do so, the custodian needs to verify the identity of the requesting party. + +In practice, many of these data exchanges are not done directly between the healthcare professionals, but between computers and systems. Often vendors operate these systems on behalf of the care organizations. + +On top of that, use-cases are often described and governed by a governing body. The governing body certifies healthcare organizations and vendors to operate in a specific use-case. The governing body defines the trust framework in which the use-case operates. The custodian also needs to verify that the entities operate within the trust framework of the use-case. + +The custodian needs to verify the identity of the requesting healthcare professional, working for an organization which is a customer of a vendor. The custodian needs to verify the following: + +- The identity of the healthcare professional: identifier, role, and affiliation with the care organization +- The identity of the care organization: identifier and its relationship with the healthcare professional +- The identity of the vendor: identifier and its relationship with the care organization + +### Solution overview + +The solution is based on exchanging verifiable identity claims between the involved parties. +The claims can be flexible combined to form a complete identity for a specific use-case. +The claims can be verified by the verifier without the need of a central authority, using cryptographic techniques. + +#### Actors and Transactions + +Overview of transactions in the authentication function. + +**Table 7.2-1: GF Authentication - Actors and Transactions** + +| Actor | Transaction | Initiator or Responder | Optionality | Reference | +|-----------|-----------------------------------------|------------------------|-------------|-----------------------------| +| Verifier | Request key material [GFI-001] | Initiator | R | [\[GFI-001\]](GFI-001.html) | +| | Request Revocation status [GFI-003] | Initiator | R | [\[GFI-003\]](GFI-003.html) | +| | Request Access Token [GFI-004] | Responder | R | [\[GFI-004\]](GFI-004.html) | +| | Introspect Access Token [GFI-006] | Responder | O | [\[GFI-006\]](GFI-006.html) | +| Holder | Issue Claims \[GFI-002\] | Responder | O | [\[GFI-002\]](GFI-002.html) | +| | Request Access Token [GFI-004] | Initiator | R | [\[GFI-004\]](GFI-004.html) | +| | Authenticated Interaction [\[GFI-005\]] | Initiator | R | [\[GFI-005\]](GFI-005.html) | +| Issuer | Issue Claims [GFI-002] | Initiator | O | [\[GFI-002\]](GFI-002.html) | +| | Request key material [GFI-001] | Responder | R | [\[GFI-001\]](GFI-001.html) | +| | Request Revocation status [GFI-003] | Responder | R | [\[GFI-003\]](GFI-003.html) | +| Custodian | Authenticated Interaction [GFI-005] | Responder | R | [\[GFI-005\]](GFI-005.html) | +| | Introspect Access Token [GFI-006] | Initiator | O | [\[GFI-006\]](GFI-006.html) | + +{: .grid .table-striped} + +#### Layered approach + +Because authentication is a complex topic, this IG tries to structure the solution in a layered approach. Each layer has its own responsibilities and can be implemented using different technologies. The layers are: + +1. Trust layer +2. Peer-to-peer layer +3. Identity claims layer +4. Application layer + +#### Trust layer + +##### Overview + +The trust layer defines techniques and governance to establish trust between entities. Each entity needs to be referenced by an identifier. +To establish trust into an entity, a verifier must be able to verify the ownership of the identifier by the entity. Some identifiers are easier to verify than others. Identifiers that can be verified are called verifiable identifiers (VIDs). +How a verifier can verify a VID depends on the type of identifier. +Identifiers can either be externally verified by an authority (XVIDs), or self-certifying (SCIDs). Many identifiers we know are externally verified, such as your phone number or bank account. +Self-certifying identifiers can be verified by a verifier without the need of a third party. An example category of a self-certifying identifier is DIDs (Decentralized Identifiers). + +Self-certifying identifiers are instrumental in peer-to-peer scenarios because they do not require a central authority to verify the identifier. This makes them suitable for use-cases where entities need to interact with each other without the need of a central authority. + +Once an entity has a verifiable identifier, it can use this identifier to link non-verifiable identifiers to its identity. This will be explained in the identity claims layer. + +##### Choice of self-certifying identifier + +The chosen solution for the trust layer is the [Decentralized Identifiers v1.0 standard](https://www.w3.org/TR/did-1.0/) with the [did:web method](https://w3c-ccg.github.io/did-method-web/). This method uses a domain name as the identifier. The domain name is owned by the entity and ownership can be verified by the verifier by resolving the public key hosted at the domain. This method is secured by DNSSEC and HTTPS which guarantees the domainname resolves to the correct webservice and the traffic is not altered. + +#### Peer-to-peer layer + +##### Overview + +The peer-to-peer layer defines the protocols and mechanisms to establish a secure communication channel between two entities. + +Each entity needs a digital agent to act on its behalf. The digital agent is responsible for managing the SCID, establishing secure communication channels with other parties, receiving and presenting identity claims. + +This layer describes the protocols and data standards which can be used between the digital agents of the involved parties to acquire, present, and verify identity claims. + +The identifier of the underlying trust layer is not that useful by itself. But when it is combined with identity claims, it becomes useful. Identity claims are statements about an entity that can be used to verify its identity in a specific context. By combining the SCID with identity claims, an entity can prove the ownership of the claims. + +##### Choice of protocols and standards + +The dataformat to express identity claims is the [Verifiable Credentials Data Model 1.1](https://www.w3.org/TR/vc-data-model/). This standard defines how to express claims in a cryptographically verifiable way. The claims can be issued by an issuer and presented by a holder to a verifier. + +To prove the ownership of a set of claims, the holder can create a [Verifiable Presentation](https://www.w3.org/TR/vc-data-model/#presentations-0) which contains one or more verifiable credentials. The verifiable presentation is signed by the holder key (which can be resolved using the method defined by the trust layer) and can be verified by the verifier. + +Verifiable credentials and presentations can be expressed in different formats. We here choose to use the JWT format, because it is widely used and supported by many libraries and tools and is compatible with existing OAuth 2.0 and OpenID Connect implementations. + +The protocol to request and issue verifiable credentials is [OpenID Connect for Verifiable Credential Issuance (OIDC4VCI)](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html). This protocol is based on OpenID Connect and OAuth 2.0 and defines how to request and issue verifiable credentials between a digital agent and an authoritative registry. + +The protocol to request access tokens is based on [RFC 7523](https://www.rfc-editor.org/rfc/rfc7523), an extension to the OAuth 2.x standard, which defines how to request access tokens using a JWT Authorization Grant combined with a Client Authentication assertion. The JWT Authorization Grant contains a Verifiable Presentation with the required identity claims. The Client Authentication assertion contains the identity of the client according, issued by an authoritative registry. + +In order to prevent token theft, the access token must be bound to the client. This can be done using [DPoP (Demonstrating Proof-of-Possession at the Application Layer)](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop). DPoP is a mechanism to bind an access token to a private key, which is used to sign an additional DPoP access token which is uniquely created for each request to the resource server. + +Verifiable credentials have a long lifetime, often several years. To be able to revoke a verifiable credential, a revocation mechanism is needed. The chosen revocation mechanism is [StatusList 2021](https://w3c-ccg.github.io/vc-status-list/), which defines a standard for revoking verifiable credentials using a bitstring. The verifier periodically retrieves (and caches) the status list and verifies the existence of the credential in the status list. + +#### Identity claims + +The identity claims layer defines the workings of specific identity claims. +Identity claims contain information about the entity such as its name, role, and affiliation. +Identity claims can also be identifiers that cannot be self-certified. +These claims are usually managed by existing governance structures such as professional branches and governmental bodies. A chamber of commerce number is a result of such a governance structure. + +The identity claims layer can be seen as the "Identification" part of the Generic Function "Identification & Authentication." + +This layer describes the information in the specific claim such as its schema. The issuer or issuers that are authorized to issue the claim and the trust framework in which the claim can be used. +It also describes the assurance levels and the lifecycle of the claim. + +In order for use-case designers to choose from the available claims, a repository is needed that keeps track of all available claims, their properties, and governance bodies. + +This IG will not define specific claims. Eventually a national repository of available claims should be established which can be used in healthcare. + +One of the challenges in architecture is crossing a gap between two technologies. Many existing identity claim technologies exist and are, for example, based on X.509 certificates or SAML assertions. These technologies are not directly compatible with the verifiable credentials technology. To bridge this gap, a mapping between the existing technologies and verifiable credentials is needed. + +This layer can specify techniques to solve interoperability, such as introducing custom proof types, introducing a trusted party which can map the information, or define custom verification methods. None of these solutions are ideal. Each solution has its own trade-offs. This layer can be used to specify building blocks to solve these interoperability challenges. + +#### Application layer + +The application layer defines requirements for specific use-cases in which authentication and authorization are required. This includes the specific set of identity claims that are required to be presented, the trust framework in which the entities operate, and the protocols and mechanisms to establish a secure communication channel. It uses the lower layers of the stack to achieve this. + +To define the required identity claims, the [Digital Credential Query Language (DCQL)](https://identity.foundation/dcql/) can be used. This standard defines a way to express the required identity claims in a machine-readable way. The holder can use the DCQL query as a form of digital contract to gather the required claims from its wallet (or other sources) and by the verifier to verify the presented claims. + +The DCQL language does not have to be implemented directly by holders or verifiers, but can be used by specifications to define the required claims in a machine-readable way. + +#### Summary of layers, technologies, and standards + +| Layer | Transaction | Technology / Standard | Description | +| ------------------ | ----------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------- | +| Trust layer | GFI-001 | DID (Decentralized Identifier) | DID method did:web, a domain name based identifier that hosts the DID document conaining the public key | +| Peer-to-peer layer | GFI-001 | OpenID Connect for Verifiable Credential Issuance (OIDC4VCI) | Protocol to request and issue verifiable credentials between digital agents and authoritative registries | +| Peer-to-peer layer | GFI-003 | [RFC 7523](https://www.rfc-editor.org/rfc/rfc7523) | JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants to request Access tokens based on a Verifiable Presentation | +| Peer-to-peer layer | GFI-005 | DPoP (Demonstrating Proof-of-Possession at the Application Layer) | Mechanism to bind an access token to a public key to prevent token theft | +| Peer-to-peer layer | GFI-003 | StatusList2021 (Revocation mechanism for VCs) | Standard for revoking verifiable credentials | +| Peer-to-peer layer | GFI-[002 | 003] | Verifiable Credentials (VC) | Standard for expressing identity claims in a cryptographically verifiable way | +| Peer-to-peer layer | GFI-003 | Verifiable Presentations (VP) | Standard for presenting a set of verifiable credentials in a cryptographically verifiable way | +| Application layer | None | Digital Credential Query Language (DCQL) | Standard for expressing the required identity claims in a specific use-case | + +{: .grid .table-striped} + +#### Identity claims repository + +Several identity claims are required to be presented. Which claims are required depends on the use-case. Each of the claims have different properties such as: + +- Who can issue the claim? +- How can the claim be verified? +- What is the level of assurance of the claim? +- Under which conditions can the claim be used? +- Lifecycle of the claim (expiration, revocation, renewal) + +In order for use-case writers to define which claims are required, a repository is needed that keeps track of the claims and their properties. + +#### Mechanics + +### The actors + +- Care organization +- Healthcare professional +- Vendor +- Verifier +- Claim Issuer + +#### Relations between the actors + +Vendors get authorized by care organizations to act on their behalf. +The care organization's identity can be represented by one of the trusted Vendors. + +### Use-cases + +Different use-cases have different requirements for identity claims. + +Each use-case requires its own governance in which it defines the necessary identity claims and the trust framework in which the actors operate. + +The following steps are required to establish the identity of a healthcare organization and professional in a specific use-case. + +##### Setup for organizations + +- Choose an identity wallet provider +- Acquire identity claims +- Choose a vendor and authorize it to act on your behalf for a specific use-case +- Issue relationship credentials to each healthcare professional + +##### Setup for healthcare professionals + +- Choose a wallet +- Acquire identity claims from DEZI and your branch organization +- Acquire relationship credentials from your care organization +- Authorize the organization to act on your behalf for a limited amount of time (e.g. 1 day) + +##### Asserting identity + +In the context of a use-case, several identity claims are required to be presented to the verifier. + +- Get a fresh nonce from the nonce endpoint of the verifier +- Gather the required claims from your wallet or other sources +- Create a verifiable presentation including the nonce +- Present the verifiable presentation to the verifier + +##### Verifying identity + +- Verify the verifiable presentation + - Verify the nonce + - Verify the signature + - Verify the expiration date +- Verify the claims + - Verify the signatures + - Verify the revocation status + - Verify the issuer + - Verify the expiration date +- Respond with a bearer token + +##### Interacting with the resource server + +- Present the bearer token to the resource server alongside the request +- Check the DPoP proof (or other token-binding mechanism) +- The resource server verifies the bearer token by introspecting it at the oauth-authorization server +- The oauth-authorization server replies with the token status and the provided identity claims +- The resource server verifies the token status +- The resource server verifies the identity claims and the relationships + +### Security considerations + +#### Token binding + +#### No sharing of private keys or certificates + +#### Use of TLS + +Use of TLS for the vendor + +#### Replay attacks + +nonce and timestamps diff --git a/input/pagecontent/authorization.md b/input/pagecontent/authorization.md index 7a00835..5d4eb98 100644 --- a/input/pagecontent/authorization.md +++ b/input/pagecontent/authorization.md @@ -16,13 +16,13 @@ A Care Plan is created by the Care Plan Service as the owner of a CarePlan. As t │ │ ┌───┴────┐ - │CarePlan┼───────────┬────────┐ - └───┬────┘ │ │ - │CPS │CPC │CPC - │ │ │ -┌────────┴─────────┐ ┌────┴───┐ ┌──┴───┐ -│General Practioner│ │Hospital│ │Physio│ -└──────────────────┘ └────────┘ └──────┘ + │CarePlan┼─────────────┬────────┐ + └───┬────┘ │ │ + │CPS │CPC │CPC + │ │ │ +┌────────┴───────────┐ ┌────┴───┐ ┌──┴───┐ +│General Practitioner│ │Hospital│ │Physio│ +└────────────────────┘ └────────┘ └──────┘ ``` ### A single context of care A Care Plan is bound to one single context, in the sense that, CSP assumes that all members of the CT are always allowed to access all relevant data. In the case they are not allowed to access all relevant data, they should not be part of the CT. This that case, a different CP should be created. If a patient is referred to another organization that should not have access to all relevant data of the patient, another (nested) CP should be created. @@ -34,25 +34,25 @@ A Care Plan is bound to one single context, in the sense that, CSP assumes that │ │ │ │ │ ┌───┴────┐ -│ │CarePlan┼───────────┬────────┐ -│ └───┬────┘ │ │ -│ │CPS │CPC │CPC -│ │ │ │ -│ ┌────────┴─────────┐ ┌────┴───┐ ┌──┴───┐ -│ │General Practioner│ │Hospital│ │Physio│ -│ └──────────────────┘ └────┬───┘ └──────┘ -│ │ -│ │CPS -│ │ -│ ┌───────┴───────┐ -└────────────────────┼Nested CarePlan│ - └───────┬───────┘ - │ - │CPC - ┌──────┴──────┐ - │Mental health│ - │care provider│ - └─────────────┘ +│ │CarePlan┼─────────────┬────────┐ +│ └───┬────┘ │ │ +│ │CPS │CPC │CPC +│ │ │ │ +│ ┌────────┴───────────┐ ┌────┴───┐ ┌──┴───┐ +│ │General Practitioner│ │Hospital│ │Physio│ +│ └────────────────────┘ └────┬───┘ └──────┘ +│ │ +│ │CPS +│ │ +│ ┌───────┴───────┐ +└──────────────────────┼Nested CarePlan│ + └───────┬───────┘ + │ + │CPC + ┌──────┴──────┐ + │Mental health│ + │care provider│ + └─────────────┘ ``` ### Model of Patients' consent diff --git a/sushi-config.yaml b/sushi-config.yaml index 1cdebb9..922fd43 100644 --- a/sushi-config.yaml +++ b/sushi-config.yaml @@ -76,6 +76,24 @@ pages: authentication.md: title: Authentication + GFI-001.md: + title: Request key material [GFI-001] + generation: markdown + GFI-002.md: + title: Issue Claims [GFI-002] + generation: markdown + GFI-003.md: + title: Request Revocation status [GFI-003] + generation: markdown + GFI-004.md: + title: Request Access Token [GFI-004] + generation: markdown + GFI-005.md: + title: Authenticated Interaction [GFI-005] + generation: markdown + GFI-006.md: + title: Token introspection [GFI-006] + generation: markdown authorization.md: title: Authorization @@ -125,7 +143,6 @@ menu: Authorization: authorization.html Artifacts: artifacts.html - # ╭───────────────────────────Less Common Implementation Guide Properties──────────────────────────╮ # │ Uncomment the properties below to configure additional properties on the ImplementationGuide │ # │ resource. These properties are less commonly needed than those above. │ @@ -258,4 +275,5 @@ instanceOptions: # Determines for which types of Instances SUSHI will automatically set id # if InstanceOf references a profile: # - # setId: always # always | standalone-only \ No newline at end of file + # setId: always # always | standalone-only +