Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RFC002 Add the NutsEmployeeIdentity means #256

Closed
wants to merge 3 commits into from
Closed

RFC002 Add the NutsEmployeeIdentity means #256

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
17d6ec3
First draft of the NutsEmployeeIdentity
stevenvegt Apr 4, 2023
402032c
Update the NutsEmployeeIdentity means spec
stevenvegt Apr 4, 2023
24fb2ad
add rfc019 and rfc020 for new authentication means
woutslakhorst Apr 26, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
78 changes: 78 additions & 0 deletions rfc/rfc002-authentication-token.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -401,3 +401,81 @@ Beside the mandatory VP fields, the following applies:
* The `proof.type` field MUST equal `NutsUziSignedContract`.
* The `proof.proofValue` field MUST contain the JWT in its compact serialization form as described in \[[RFC7515 section 3.1](https://tools.ietf.org/html/rfc7515#section-3.1)\].

### 7.3 NutsEmployeeIdentity
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

UZI and IRMA means are called just so, NutsEmployeeIdentity is the name of the credential. I think the means should be called something along the line of "Self-claimed Employee Identity" or just "Employee Identity".

Also; should be now add levels of assurances to the methods we spec'd? (or refer to a framework we use, e.g. eIDAS(2)?)


The NutsEmployeeIdentity method is an authentication _means_ which allows a care organisation to assert the identity of the current user. The care organisation uses the information of the current user session to present the user with a statement about its identity and asks the user to confirm this. After confirmation this bundle of information is singed with the care organisation's public key.
stevenvegt marked this conversation as resolved.
Show resolved Hide resolved

This method makes it possible to assert a user identity without the need for a personal authentication means. This puts the care organisation in the role of identity issuer instead of a trusted third party. A use-case (Bolt) can choose to allow this authentication under certain (low risk) circumstances which still require a person to be authenticated in order to comply with the requirements of the [NEN7513](https://www.nen.nl/nen-7513-2018-nl-245399)(Dutch standard for logging in context of medical ICT).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just call it "applicable legislation"? So the rfcs remain relatively free of national context?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made it an example. Since it is pretty relevant and there are more national things in this spec such as IRMA anyway.


Note: The _means_ is designed in a way that it is interchangeable with (other) means with a higher trust level, (using a personal authentication device). Even it is technically possible, this means MUST NOT be used to perform machine to machine interactions which are not initiated by the current user, e.g. background jobs, fetching data automatically etc. By doing so, a use-case (Bolt) can not update the trust level of a means without braking functionality. This means MUST only be used to claim the identity of actual and identifying natural persons working under the responsibility of the care organisation, and MUST NOT identify e.g. shared accounts, teams, administrators, dummy or test users.

#### 7.3.1 Attributes

In order for the Nuts node to sign the contract 4 things are needed:
stevenvegt marked this conversation as resolved.
Show resolved Hide resolved

1. The challenge in the form of a login contract
2. The issuing care organisation
stevenvegt marked this conversation as resolved.
Show resolved Hide resolved
3. Personal information about the person (user)
4. The employee role which contains information about the relationship between the care organisation and the user

#### 7.3.2 Challenge
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A credential specification as input is a bit weird. What if we use the presentation exchange format? That would actually also be helpful for any OIDC capable wallet.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we want to write a parser for that at the moment. Also, I think this is technically the credential, issued by the care provider which we let the user present by "signing the contract". By adding a @context, all these fields have a type and meaning. I used the relational model from schema.org, no custom fields were added.

The following object is an example of the parameters which can be used to initialize a signing session:

```json
{
"challenge": "LOGIN CONTRACT",
"credential": {
"@context":[
"http://schema.org/",
"https://www.w3.org/2018/credentials/v1"
],
"type": ["VerifiableCredential"],
"issuer":"did:nuts:123456789",
"credentialSubject": {
"@type": "EmployeeRole",
"identifier": "481",
"roleName": "Verpleegkundige niveau 2",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can't standardize identifier and roleName yet. This is not part of the current problem and will open up discussions that are not needed at this point.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is the medewerkernummer, which ensures a unique identifier. I improved the spec to have either an unique identifier or an email address. The combination initials and family name is not guaranteed unique. I suspect the employee identifier is probably more available than an email address.
I made the roleName optional.

"member": {
"@type": "Person",
"initials": "J",
"familyName": "van Dijk",
"email": "j.vandijk@example.com"
}
}
}
}
```

#### 7.3.3 Response
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What should a verifier check, on the response?


```json
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"http://schema.org/"
],
"type": "VerifiablePresentation",
"verifiableCredential": {
"issuer": "did:nuts:123456789",
"type": "VerifiableCredential",
"credentialSubject": {
"@type": "EmployeeRole",
"identifier": "481",
"roleName": "Verpleegkundige niveau 2",
"member": {
"@type": "Person",
"initials": "J",
"familyName": "van Dijk",
"email": "j.vandijk@example.com"
}
}
},
"proof": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Normally" the proof is signed by the credentialSubject. That is a problem in this case. We can either:

  • make a custom presentationType that indicates that the proof signature is from the same party as the credential issuer. Use a custom validator for that.
  • issue the credential to a did:key and sign it with that key. That would then be an ephemeral key, only used once. Can reuse current proof validation. We would have to add the did:key method though.

So either throw away code or a little bit of extending functionality.

"type": "JsonWebSignature2020",
"verificationMethod": "did:nuts:123456789#key-1",
"challenge": "LOGIN CONTRACT",
"created": "2023-04-03T16:34:17.687862+01:00",
"jws": "eyJhbGciOiJFUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..hKcboC8m6YnZPi6ReJAYs0J0Ztn5nxcx2EavoXdtrkWxmE1JZmImW89_8IIgjvfI8XtGeDlEnGywAuY2u7y9Bw"
}
}
```