RFC002 Add the NutsEmployeeIdentity means #256

stevenvegt · 2023-04-04T10:43:09Z

This PR is a RFC for the NutsEmployeeIdentity which allows a care organisation to construct a claim about a current logged-in user.
Since the user identity is issued by the care origanisation instead of a trusted third party (such as the government), it has a low trust level, but also comes with a simpler UX. It can be used in situations where a lower level of trust is appropriate and and then removes an extra burden from the care givers of using a personal authentication device.

woutslakhorst

RFC002 is part of spec v1.0. I think you need to create a new RFC that amends rfc002.
Also new sentences may be put on a new line, this will make it easier to spot differences in a diff when updated.

rfc/rfc002-authentication-token.md

woutslakhorst · 2023-04-04T11:17:15Z

rfc/rfc002-authentication-token.md

+
+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.
+
+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).


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

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

rfc/rfc002-authentication-token.md

woutslakhorst · 2023-04-04T11:23:58Z

rfc/rfc002-authentication-token.md

+    "credentialSubject": {
+      "@type": "EmployeeRole",
+      "identifier": "481",
+      "roleName": "Verpleegkundige niveau 2",


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.

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.

woutslakhorst · 2023-04-04T11:25:42Z

rfc/rfc002-authentication-token.md

+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


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.

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.

stevenvegt · 2023-04-04T15:10:45Z

RFC002 is part of spec v1.0. I think you need to create a new RFC that amends rfc002.

Not sure how a new RFC will solve that problem? I don't like that option since it make thinks harder to find. Also, we explicitly state in section 7.1:

Future means will be added when available.

Which is what we do now.

More information about the request fields Adds evidence in response made some fields optional PR feedback

woutslakhorst · 2023-04-05T07:53:15Z

RFC002 is part of spec v1.0. I think you need to create a new RFC that amends rfc002.

Not sure how a new RFC will solve that problem? I don't like that option since it make thinks harder to find. Also, we explicitly state in section 7.1:

Future means will be added when available.

Which is what we do now.

Well, then we would have to have a conversation about how we create specifications somewhere in the future. RFCs are not meant to change. So we either use RFCs or have versioned specs. But not a mix.

woutslakhorst · 2023-04-05T08:01:23Z

A simplification for the credential could be:

The credentialSubject which contains the following information:
1. The @type which contains the EmployeeRole type to indicate the contents describes a EmployeeRole as defined by schema.org
2. The identifier which contains the employee number, username or email. This identifier MUST uniquely identify one natural person within the care organisation.
3. The roleName (optional) which contains the name of the role of the person during this user session.
4. The member which contains the following information:
- The @type which contains the Person type.
- The initials which contains the initials of the person.
- The familyName which contains the last name of the person.

This would remove some if-this-then-that logic. email is really only needed as unique identifier.

woutslakhorst · 2023-04-05T08:04:41Z

rfc/rfc002-authentication-token.md

+  "evidence": {
+    "type": "NutsBrowserSession",
+    "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36 Edg/111.0.1661.62",
+    "ipAddress": "127.0.0.1"


The evidence is debatable. This data is new as opposed to the current authentication methods. What is the requirement to add this data?

woutslakhorst · 2023-04-05T08:16:15Z

rfc/rfc002-authentication-token.md

+    "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36 Edg/111.0.1661.62",
+    "ipAddress": "127.0.0.1"
+  },
+  "proof": {


"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.

reinkrul · 2023-04-05T09:03:26Z

rfc/rfc002-authentication-token.md

+   * The `credentialSubject` which contains the following information:
+      1. The `@type` which contains the `EmployeeRole` type to indicate the contents describes a EmployeeRole as defined by schema.org
+      2. The `identifier` (optional) which contains the employee number or username. This identifier MUST uniquely identify one natural person within the care organisation. If this number is not available, the email address field of the `Person` MUST be used.
+      3. The `roleName` (optional) which contains the name of the role of the person during this user session.


Why add this? Is the verifying party supposed to do something with it? If so, is it standardized? (if not, it's probably useless for the verifying party).

reinkrul · 2023-04-05T09:03:35Z

rfc/rfc002-authentication-token.md

+         1. The `@type` which contains the Person type.
+         2. The `initials` which contains the initials of the person.
+         3. The `familyName` which contains the last name of the person.
+         4. The `email` (optional) which contains the email address of the person. If the email is not available, the `identifier` field of `EmployeeRole` MUST be present.


reinkrul · 2023-04-05T09:04:52Z

rfc/rfc002-authentication-token.md

@@ -401,3 +401,129 @@ 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
+
+The NutsEmployeeIdentity method is an authentication _means_ which allows a care organisation to assert the identity of the current user.


"a care organization", is this the care organization making a statement on the user's identity, or the party verifying it?

reinkrul · 2023-04-05T09:05:28Z

rfc/rfc002-authentication-token.md

+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 private key.
+
+This method makes it possible to assert a user identity without the need for a personal authentication means.


with lower level of assurance (LoA). Now it's only a note, but it's a very important trait of this authentication means.

reinkrul · 2023-04-05T09:06:55Z

rfc/rfc002-authentication-token.md

+The proof section MUST contain the `challenge` from the request.
+
+To add further accountability, an `evidence` SHOULD be added.
+This object MUST be of the type `NutsBrowserSession` which SHOULD contain the `user-agent` field and the `ipAddress` field.


reinkrul · 2023-04-05T09:07:07Z

rfc/rfc002-authentication-token.md

+The response MUST contain a signed VerifiableCredential with a signature from the issuing care organisation.
+This credential is contained in a VerifiablePresentation. 
+The presentation contains a proof with a signature.
+Since the user doesn't have a private key, the private key from the care organisation is also used to sign the presentation.


reinkrul · 2023-04-05T09:07:40Z

rfc/rfc002-authentication-token.md

+}
+```
+
+#### 7.3.3 Response


What should a verifier check, on the response?

reinkrul · 2023-04-05T09:08:25Z

rfc/rfc002-authentication-token.md

+### 7.3 NutsEmployeeIdentity
+
+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.


Suggested change

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.

The attesting 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.

reinkrul · 2023-04-05T09:10:40Z

rfc/rfc002-authentication-token.md

@@ -401,3 +401,129 @@ 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


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)?)

reinkrul · 2023-04-05T09:44:55Z

rfc/rfc002-authentication-token.md

+2. The `credential` which contains the following information:
+   * The `@context` which MUST contain the following urls:
+      1. `http://schema.org/`: contains the Organisation, employeeRole and person types.
+      2. `https://nuts.nl/credentials/v1`: contain definition of the `NutsEmployeeIdentityCredential` type.


actually a bit of an oddball VC since it's a VC for an employee, but comes from the wallet of the care organization (rather than a personal wallet). It's sort of a shortcut since the employee doesn't have an SSI wallet with an EmployeeIdentity credential?

Unless you give the employee a ephemeral wallet (did:key)?

reinkrul · 2023-04-05T09:45:41Z

rfc/rfc002-authentication-token.md

+   * The `issuer` which contains the DID of the care organisation. This DID MUST resolve to a DID Document which contains the public key used to sign the credential.
+   * The `credentialSubject` which contains the following information:
+      1. The `@type` which contains the `EmployeeRole` type to indicate the contents describes a EmployeeRole as defined by schema.org
+      2. The `identifier` (optional) which contains the employee number or username. This identifier MUST uniquely identify one natural person within the care organisation. If this number is not available, the email address field of the `Person` MUST be used.


Maybe this should be in the "evidence" field? You could see it as evidence of the existence of the employee in the organization's user directory

First draft of the NutsEmployeeIdentity

17d6ec3

stevenvegt changed the title ~~Add the NutsEmployeeIdentity means~~ RFC002 Add the NutsEmployeeIdentity means Apr 4, 2023

woutslakhorst reviewed Apr 4, 2023

View reviewed changes

Update the NutsEmployeeIdentity means spec

402032c

More information about the request fields Adds evidence in response made some fields optional PR feedback

woutslakhorst reviewed Apr 5, 2023

View reviewed changes

reinkrul requested changes Apr 5, 2023

View reviewed changes

reinkrul reviewed Apr 5, 2023

View reviewed changes

add rfc019 and rfc020 for new authentication means

24fb2ad

woutslakhorst closed this Apr 26, 2023

woutslakhorst mentioned this pull request Apr 26, 2023

RFC019 and RFC020: Add selfsigned auth means and assuranceLevel #260

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RFC002 Add the NutsEmployeeIdentity means #256

RFC002 Add the NutsEmployeeIdentity means #256

stevenvegt commented Apr 4, 2023

woutslakhorst left a comment

woutslakhorst Apr 4, 2023

stevenvegt Apr 4, 2023

woutslakhorst Apr 4, 2023

stevenvegt Apr 4, 2023

woutslakhorst Apr 4, 2023

stevenvegt Apr 4, 2023

stevenvegt commented Apr 4, 2023

woutslakhorst commented Apr 5, 2023

woutslakhorst commented Apr 5, 2023 •

edited

Loading

woutslakhorst Apr 5, 2023

woutslakhorst Apr 5, 2023

reinkrul Apr 5, 2023

reinkrul Apr 5, 2023

reinkrul Apr 5, 2023

reinkrul Apr 5, 2023

reinkrul Apr 5, 2023

reinkrul Apr 5, 2023

reinkrul Apr 5, 2023

reinkrul Apr 5, 2023 •

edited

Loading

reinkrul Apr 5, 2023

reinkrul Apr 5, 2023

woutslakhorst Apr 7, 2023

reinkrul Apr 5, 2023 •

edited

Loading


		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.

		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).

	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.
	The attesting 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.

RFC002 Add the NutsEmployeeIdentity means #256

RFC002 Add the NutsEmployeeIdentity means #256

Conversation

stevenvegt commented Apr 4, 2023

woutslakhorst left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stevenvegt commented Apr 4, 2023

woutslakhorst commented Apr 5, 2023

woutslakhorst commented Apr 5, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

reinkrul Apr 5, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

reinkrul Apr 5, 2023 • edited Loading

Choose a reason for hiding this comment

woutslakhorst commented Apr 5, 2023 •

edited

Loading

reinkrul Apr 5, 2023 •

edited

Loading

reinkrul Apr 5, 2023 •

edited

Loading