Discovery Service RFC

[reinkrul]

Things to decide on:

• Do we want to use PEX to determine what credentials to present? Otherwise, implementations will have to hardcode how to build presentations (with which credentials) for each list. It can then also be used to validate presentations to be added to the list. Presentation definitions can be distributed out-of-band, or hosted by the list (e.g. query /<list-endpoint>/metadata.json) -> decided have a use case definitions, created by use case maintainers and shared with all users of the use case
• The list is now just that: a list of presentations. It's hard for clients to see which entries changed (were added/removed), which might be useful since checking the presentations might become (more) expensive when the list grows (e.g. entries might be converted to a SQL table for searchability). But recognizing presentations is hard, options: -> decided to let clients query deltas
  • Use presentation.ID, but guaranteeing uniqueness is hard/impossible (since it's set by the presentation creator)
  • Use hash of the presentation (JWT can be hashed as-is, for JSON-LD maybe use proof hash/signature?)

[woutslakhorst]

• yes we want to use PEX for credential selection. It is distributed by the use case.
• use jwt_vc and check the jti, iat and exp. If still valid check DB for jti, if not present, check signature.

[woutslakhorst]

Remove JSON-LD support since the semantic meaning is not used. There's only a check against the PD. This could also allow for forward compatibility. JSON-LD will definitely not be forward compatible.

[reinkrul]

Wouldn't it be better to replace state with timestamps or a lamport clock? Timestamps don't require any additional storage but suffer from nanosecond race conditions. A lamport clock doesn't suffer from this, any new POST is just a +1. This could also help with a tombstone list: [~57, 59, 60], up to 57 are removed as well as 59 and 60.

I had this exact same realization.

[jorritspee]

Sorry to enter the dialogue late and without proper preparation. My question is whether you guys see a relation between the use case list and the DCAT-standard or not? DCAT is mentioned often in relation to FAIR-datapoints.

[reinkrul]

Sorry to enter the dialogue late and without proper preparation. My question is whether you guys see a relation between the use case list and the DCAT-standard or not? DCAT is mentioned often in relation to FAIR-datapoints.

I had to look up DCAT, but I understand it describes the models of the data sets. The goal of this RFC is to define a way to discover parties (and ultimately services) supporting a certain feature/use case, but not how information/data exchanged within that use case is structured/modeled.

I could imagine use case definitions could include URLs/references to a schema or catalog describing the information model of the use case. On the other hand, the Nuts node does not deal with the actual information itself (which is exchanged directly between the XIS's). But, if the use case definition would be used in other systems (than the Nuts node), it might have some value?

[jorritspee]

Sorry to enter the dialogue late and without proper preparation. My question is whether you guys see a relation between the use case list and the DCAT-standard or not? DCAT is mentioned often in relation to FAIR-datapoints.

I had to look up DCAT, but I understand it describes the models of the data sets. The goal of this RFC is to define a way to discover parties (and ultimately services) supporting a certain feature/use case, but not how information/data exchanged within that use case is structured/modeled.

I could imagine use case definitions could include URLs/references to a schema or catalog describing the information model of the use case. On the other hand, the Nuts node does not deal with the actual information itself (which is exchanged directly between the XIS's). But, if the use case definition would be used in other systems (than the Nuts node), it might have some value?

Hi Rein, Thanks for your reply. DCAT is generally used by a partner to publish what data sets and/or - services a party provides. I would think that a use case could map to a data service. @hietkamp, you also had some ideas on using DCAT in a Nuts context didn't you?

[reinkrul]

Renamed to Discovery Service with Client and Server, removed tombstone set in favor of "just" a Verifiable Presentation that refers a retracted Verifiable Presentation.

[hietkamp]

We plan to agree on a data catalog (dcat2) with KIK-V. This would be a service address in Nuts to an endpoint where the data catalog can be found. The data catalog is intended to provide information about the datasets you offer and in accordance with which standard you offer this data (the ontology in KIK-V).

I myself see more value in mentioning the ontology (you can call it a domain model) that you support. You make data available in accordance with an (version of an) ontology. The principle is that we want to separate data and functionality.

An ontology is suitable for a use case, that's what you agree on. But the ontology can also be used for many other use cases. The use case is also owned by the data user and not the data holder in my experience. Then it is strange that the holder specifies the use cases for which his data is suitable.

The RFC therefore plays into the use case-driven way of working while we want to move towards a data-driven way of working. We may still need this for the first plateau of the NVS, but then we will immediately build an architectural debt towards the second plateau of the NVS.

[woutslakhorst]

Then it is strange that the holder specifies the use cases for which his data is suitable.

A lot of the current development for data exchange is use-case oriented and even defines a specific information model per use-case. If all those models converge in the future, there indeed could be a 'single use-case' that only requires a party to publish its data catalog endpoint. This discovery service would then still be useable. It would be a single use-case, single instance usage. A way to discover other endpoints will always be required.

[woutslakhorst]

@reinkrul is the name/id of the use case included in the VP? Otherwise you can replay a VP to another use case....

[reinkrul]

Renamed "timestamp" to "tag", as it is an opaque value. "Timestamp" suggests it's a time-based property, which it might not be.

[reinkrul]

@reinkrul is the name/id of the use case included in the VP? Otherwise you can replay a VP to another use case....

This is now included;

• aud MUST contain the ID of the service.

[reinkrul]

JWT-VC profile

VC Data Model v1.1 specifies that “issuanceDate” property MUST be represented as an nbf JWT claim, and not iat JWT claim. This might sound couterintuitive, but the implementers of this profile MUST follow this guidance.

Do we need a similar statement? (If only to prevent reconsidering/discussions in the future)

If we already refer to VC 1.1, it's covered? (Since it's a MUST)