Add authentication #22
Conversation
4 layers, loosely based on ToIP model describing it's responsibility and choices.
A GF-Interaction describes a set of relevant interactions between several actors. This commit add GFI 1, 2 and 3.
Adds detailed description about requesting an access token using RFC7523 and VPs.
…r" to "General Practitioner" and aligned diagram text accordingly.
There was a problem hiding this comment.
Pull Request Overview
This PR adds comprehensive authentication functionality to the healthcare implementation guide, introducing a peer-to-peer authentication system based on verifiable credentials and decentralized identifiers. The authentication system is designed to support healthcare professionals and organizations accessing patient data across organizational boundaries while maintaining privacy and security.
Key changes include:
- Addition of six transaction types (GFI-001 through GFI-006) covering the complete authentication workflow
- Implementation of a layered authentication architecture using DIDs, verifiable credentials, and OAuth 2.0 extensions
- Support for token introspection, access token requests, and authenticated interactions
Reviewed Changes
Copilot reviewed 14 out of 15 changed files in this pull request and generated 14 comments.
Show a summary per file
| File | Description |
|---|---|
| sushi-config.yaml | Updated page configuration to include new authentication transaction pages |
| input/pagecontent/authorization.md | Fixed ASCII art diagrams and corrected spelling of "Practitioner" |
| input/pagecontent/authentication.md | Added comprehensive authentication documentation with layered architecture |
| input/pagecontent/GFI-001.md | Defined DID document resolution transaction |
| input/pagecontent/GFI-002.md | Defined verifiable credential issuance transaction |
| input/pagecontent/GFI-003.md | Defined credential revocation status checking transaction |
| input/pagecontent/GFI-004.md | Defined OAuth 2.0 access token request transaction |
| input/pagecontent/GFI-005.md | Defined authenticated API interaction transaction |
| input/pagecontent/GFI-006.md | Defined access token introspection transaction |
| input/images-source/*.plantuml | Added PlantUML diagrams for transaction flows |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
There was a problem hiding this comment.
Pull Request Overview
Copilot reviewed 14 out of 15 changed files in this pull request and generated 5 comments.
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
There was a problem hiding this comment.
Pull Request Overview
Copilot reviewed 14 out of 15 changed files in this pull request and generated 3 comments.
Comments suppressed due to low confidence (1)
input/pagecontent/authentication.md:1
- The table formatting is broken with split cell content across multiple rows. The GFI transaction references should be properly formatted in a single cell.
### Introduction
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
|
|
||
| authentication.md: | ||
| title: Authentication | ||
| GFI-001.md: |
There was a problem hiding this comment.
The indentation for GFI transaction pages is inconsistent. They should be indented under 'authentication.md' to show the hierarchical relationship.
Copilot uses AI. Check for mistakes.
input/pagecontent/authentication.md
Outdated
|
|
||
| - Work with identity claims from the authoritative sources | ||
| - Support combinations of identity claims from different trusted issuers | ||
| - Support for use-cases with and without a end-user (healthcare professional) |
There was a problem hiding this comment.
Corrected article usage from 'a end-user' to 'an end-user'.
| - Support for use-cases with and without a end-user (healthcare professional) | |
| - Support for use-cases with and without an end-user (healthcare professional) |
Copilot uses AI. Check for mistakes.
|
|
||
| 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. |
There was a problem hiding this comment.
Corrected abbreviation from 'e.t.' to 'e.g.' (exempli gratia).
| 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 an authorization server is shared between multiple (care) organizations (e.g. 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. |
Copilot uses AI. Check for mistakes.
…ntation; standardize "organization", align terminology, and improve readability. Use of American English like the other md files in this IG.
2 participants
https://build.fhir.org/ig/nuts-foundation/nl-generic-functions-ig/branches/authentication/authentication.html