Introduce URNs to identify Bolts, access policies, roles and services

[reinkrul]

We currently don't have a structured format for identifying Bolts but, more importantly, services and their access policies (e.g. eOverdracht-receiver). While this doesn't pose a problem for current implementations, it allows for ambiguous, incorrect, conflicting or non-descriptive identifiers to emerge in the future. For instance, the current de facto format is <bolt>-<role/access policy> which can be parsed, but it is not enforced or a standardized. In addition, it eliminates discussion and possible bugs about capitalization (eOverdracht v.s. eoverdracht) since they're lexically equivalent.

I would like to propose changing these free-format identifiers to URNs, structured in such way that related identifiers (bolt identifier, service, and access policy) that they can be related by software as well, without having to rely on non-standard parsing. Which means, not having to rely on string splitting on whatever characters the Bolt decides to use.

urn:nuts:<bolt>:<profile>:<role>

Examples:

urn:nuts:zorginzage:geboortezorg:bronhouder

The "profile", however applicable to eOverdracht, might be a bit difficult though: it certainly has profiles (the one currently supported is "overdracht van ziekenhuis naar thuiszorg"), but they lack a short identifier which would make the URN long and possible cumbersome.

Another advantage is that (localized) tables with display titles can be easily provided, since the label keys follow a structured format.

Related to nuts-foundation/nuts-specification#165

[reinkrul]

@woutslakhorst @stevenvegt I would like to discuss this next monday.

[stevenvegt]

Needs more examples which explains the difference between services roles and access policies.