Metadata for participants

A participant MUST supply metadata to the Beheerorganisatie (BO) for every system that implements the role of HM, AD, MR, EB or KR in the network. A participant MUST NOT supply metadata for a role or functionality it has not been assigned.

This requirement is for metadata for the production network. This requirement does not apply to metadata for the test network, because it must also be possible to test the systems of parties that have not yet joined.

A participant that has several roles in the network MUST supply metadata for each role separately.

EntityDescriptor

The participant MUST publish SAML metadata for the Beheerorganisatie complying to the specifications defined for the namespace urn:oasis:names:tc:SAML:2.0:metadata, with one signed EntitiesDescriptor element. Signing metadata MUST meet the requirements for signing, see Digital signature.

The EntitiesDescriptor element MUST contain an attribute Name with a value formatted as urn:etoegang:<scheme version>:<omgeving>:<sequence number>, whereby <scheme version> indicates the version of the framework, <omgeving> the respective environment (P or T), and <sequence number> is a sequence number that distinguishes the different versions of metadata.

The EntitiesDescriptor MAY contain an Extensions element that contains a PublicationInfo element with the URL and creation date of the metadata file.

The EntitiesDescriptor element contains one or more EntityDescriptor elements.

Each EntityDescriptor element MUST contain the EntityID and an additional version attribute, MAY contain a SAML validUntil, EH validFrom, name and ISOname attributes and MUST NOT contain other SAML attributes. The version attribute contains the version of the interface specifications on which the entity communicates. The additional attributes are described below.

The EntityDescriptor MUST contain one or more elements of the type ContactPerson containing an administrative non-personal name, email address, and telephone number that can be contacted by participants or the Beheerorganisatie in the event of an incident. The field 'company' is optional for Contactperson but may be filled in. In case the Contactperson is employed by a different company, the field 'company' of the contactperson MUST be filled in. "The metadata MUST NOT contain personally identifiable information in the sense of the GDPR/AVG.

The metadata MUST contain data about one's own organization by including one element of the type Organization, which describes the name (OrganizationName), the readable name for users (OrganizationDisplayName), and the website (OrganizationURL).

The same role MAY be filled by several systems. Metadata is supplied for each of the systems. The metadata MUST contain a different EntityID in which the Organization element is the same.

urn:etoegang:1.13:metadata-extension

ValidFrom	1	Electronische toegangsdiensten: For communicating a time specific change on an Entity, a participant can use SAML attribute validUntil and Elektronische Toegangsdiensten specific attribute validFrom (see schema below) on the EntityDescriptor. This can for instance be used to facilitate the transition to a new version, replacing certificates, etc...
Version	1	Electronische toegangsdiensten: Denotes the ETD version of an endpoint.
Name	1	Electronische toegangsdiensten: MUST be included if there is more than one SingleSignOnService element defined
ISOName	1	Electronische toegangsdiensten: MAY be implemented to denote the countrycode (formatted according ISO 3166-1 alpha-2 for an endpoint. MAY be used by other configuration elements.

Example Participant EntitiesDescriptor

XML

<?xml version="1.0" encoding="UTF-8"?>
<md:EntitiesDescriptor
    ID="[reference for dsig]"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:mdrpi="urn:oasis:names:tc:SAML:metadata:rpi"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:eme="urn:etoegang:1.13:metadata-extension"
    Name="urn:etoegang:1.13:metadata:P:23">
 
    <ds:Signature>...</ds:Signature>    
    <md:Extensions>
        <mdrpi:PublicationInfo publisher="https://.../productie_metadata.xml" creationInstant="2019-04-07T10:39:03Z"/>
    </md:Extensions>
  
    <md:EntityDescriptor
        entityID="urn:etoegang:HM:9999990000010000:entities:0001"
        eme:version="1.9"
        eme:validFrom="2019-04-01T0:04:00Z">
        ...
        <md:Organization>
            ...
        </md:Organization>
        ...
        <md:ContactPerson>
            ... 
        </md:ContactPerson>
    </md:EntityDescriptor>
  
</md:EntitiesDescriptor>

Versions

When a system can send messages based on different versions of the framework, metadata MUST be supplied for each version. So, if an entity can communicate on several versions of the interface, both are included in the EntitiesDescriptor as separate EntityDescriptor. These EntityDescriptor elements MAY have the same or different EntityIDs.

An HM MUST include separate EntityDescriptor elements in the metadata for the different logical systems that support the individual versions of the Elektronische Toegangsdiensten interfaces. So, an HM that can communicate on several versions of the interface will include both versions in the metadata as separate EntityDescriptor in the EntitiesDescriptor. These EntityDescriptors MAY have the same or different values for their EntityID attributes.

An AD/KR/MR MUST inspect the values of version in the metadata to determine which EntityDescriptor is to be used to communicate with an HM. Only communication details from the applicable version MUST be used for processing requests and for authentication and securing of communication.

ValidFrom and ValidUntil

For communicating a time specific change on an Entity, a participant can use SAML attribute validUntil and Elektronische Toegangsdiensten specific attribute validFrom (see schema below) on the EntityDescriptor. This can for instance be used to facilitate the transition to a new version, replacing certificates, etc...

An HM MAY have one valid EntityDescriptor per supported version at any given time. If validFrom and/or validUntil are present, an AD/KR/MR MUST only accept requests from an HM using the communication details from a valid EntityDescriptor.

An AD/KR/MR has only one valid EntityDescriptor at a given point in time. An AD/KR/MR MAY provide exactly two different EntityDescriptor elements, one of these EntityDescriptor elements MUST contain a validUntil, the other EntityDescriptor element MUST contain a validFrom. The dateTime value of both fields MUST be the same. These two EntityDescriptors MAY have the same or different EntityIDs. An HM MUST use the validFrom and validUntil in the metadata, if present, to determine which EntityDescriptor is valid for communication with an AD/KR/MR.

Different EntityDescriptor elements for the same role MUST always be contained in a single EntitiesDescriptor element.

See example Example 2 ED - versions and validity.1.13.xml

Level of assurance

An AD or MR MUST include the Level of assurance at which recognition requests can be processed in the EntityDescriptor, in the form of an extension of the EntityDescriptor element as described in the document SAML V2.0 Identity Assurance Profiles.

Example LoA

XML

... 
    <md:Extensions xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
        xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"
        xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

        <mdattr:EntityAttributes> 
            <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:SAML:attribute:assurance-certification"> 
                <saml:AttributeValue>urn:etoegang:assurance-class:loa3</saml:AttributeValue>
            </saml:Attribute>
        </mdattr:EntityAttributes>

    </md:Extensions> 
...

Discovery endpoint

An MR MUST include an endpoint which can be used by other MR's for the discovery service as specified on Discovery webservice MR for chain authorisations This endpoint is defined as an attribute in the following manner:

Attribute name	Value
Name	urn:etoegang:service:discovery:V1
NameFormat	urn:oasis:names:tc:SAML:2.0:attrname-format:uri
AttributeValue	<URL VALUE OF ENDPOINT>

Example discovery endpoint

XML

<md:EntityDescriptor eme:version="1.13" entityID="urn:etoegang:MR:...:entities:....">
    <md:Extensions>
        <mdattr:EntityAttributes>
            ...
            <saml:Attribute
                    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
                    Name="urn:etoegang:service:discovery:V1">
                <saml:AttributeValue>https://example.mr.nl/discoveryEndpoint</saml:AttributeValue>
            </saml:Attribute>
			...
        </mdattr:EntityAttributes>
    </md:Extensions>
    ...
</md:EntityDescriptor>

RoleDescriptors

AD IDPSSODescriptor

An AD MUST include one IDPSSODescriptor element. The descriptor MUST contain at least one SingleSignOnService element, one SingleLogoutService and at least one ArtifactResolutionService element. The descriptor MUST NOT include any other elements. The first SingleSignOnService MUST indicate it supports the SAML Artifact Binding with the attributes Binding and Location. In case multiple SingleSignOnService elements are present, each MUST have an eme:name attribute, allowing Users to select an applicable endpoint. A SingleSignOnService and SingleLogoutService elements MUST indicate it supports the SAML Artifact binding with the attributes Binding and Location, and MUST NOT contain any other attributes.

AD Example Descriptor

XML

...
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="true">
    ...
    <md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://..." index="1" />
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://...."/>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://...." eme:name="AD1SAMLendpoint1"/>
    ...
</md:IDPSSODescriptor>
...

MR IDPSSODescriptor

A MR MUST include one IDPSSODescriptor element. The descriptor MUST contain at least one SingleSignOnService elements and at least one ArtifactResolutionService element. The descriptor MUST NOT include any other elements. The first SingleSignOnService and SingleLogoutService elements MUST indicate it supports the SAML Artifact binding with the attributes Binding and Location, and MUST NOT contain any other attributes. In case a MR supports chain authorizations, another SingleSignOnService element MUST be present, with the indication it supports the SAML SOAP binding with the attributes Binding and Location, and MUST NOT contain any other attributes. The SingleLogoutService MUST NOT be defined as part of the MR IDPSSODescriptor element.

MR Example Descriptor

XML

...
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="true">
    ...
    <md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://..." index="1" />
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://...." eme:name="AD1SAMLendpoint1"/>
    ...
</md:IDPSSODescriptor>
...

EB IDPSSODescriptor

The eIDAS-berichtenservice (EB) MUST provide an IDPSSODescriptor in its metadata, identical to one an AD/MR would supply.

HM SPSSODescriptors

An HM MUST include only one IDPSSODescriptor and only one SPSSODescriptor and MUST NOT include any other elements. The IDPSSODescriptor from the HM MAY contain several SingleSignOnService and SingleLogoutService elements and MUST contain at least one SingleSignOnService and one SingleLogoutService element for which the Binding attribute has the value urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact. The SPSSODescriptor from the HM MUST contain two AssertionConsumerService elements with a Binding attribute which has the value urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact, and with indices 1 and 2 for responses from ADs and MRs, MUST contain at least one ArtifactResolutionService element with the SOAP binding and MAY NOT contain any other elements.

If the HM offers support for eIDAS, the the SPSSODescriptor from the HM MUST contain one (extra) AssertionConsumerService element with a Binding attribute which has the value urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact, and with index 5.

Example HM descriptor

XML

...
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="true">
    ...
    <md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://..." index="1" />
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://...."/>
    ...
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://...."/>
	...
</md:IDPSSODescriptor>
<md:SPSSODescriptor AuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    ...
    <md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://..." index="1" />
    ...
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://..." index="1"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://..." index="2"/>
 </md:SPSSODescriptor>
...

BSNk

BSNk fulfills two roles within the Netwerk (voor Elektronische Toegangsdiensten):

The role of Sleutelbeheerder (SB).
The role of cryptographic service provider.

The BSNk is a special participant as the Beheerorganisatie (BO) uses the metadata published (and as specified) by the BSNk (Link will follow)

Example metadata BSNk

XML

<md:EntityDescriptor entityID="urn:nl-gdi-eid:entity:99999999012345670000"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
     <md:IDPSSODescriptor WantAuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <md:KeyDescriptor use="signing">
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>...</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </md:KeyDescriptor>
        <md:KeyDescriptor use="encryption">
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>...</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </md:KeyDescriptor>
        <md:KeyDescriptor>
            <ds:KeyInfo>
                <!--  PIP/PP/PI public signing key U for BSNk-activate in test network -->
                <ds:KeyName>urn:nl-gdi-eid:pp-key:test:1:U:1</ds:KeyName>
                <ds:KeyValue>
                    <ds11:ECKeyValue>
                        <ds11:NamedCurve URI="urn:oid:1.3.36.3.3.2.8.1.1.9"/>
                        <ds11:PublicKey>Mwo=...</ds11:PublicKey>
                    </ds11:ECKeyValue>
                </ds:KeyValue>
            </ds:KeyInfo>
        </md:KeyDescriptor>
        <md:NameIDFormat>urn:nl-gdi-eid:1.0:id:Pseudonym</md:NameIDFormat>
        <md:NameIDFormat>urn:nl-gdi-eid:1.0:id:BSN</md:NameIDFormat>
        <md:SingleSignOnService Location="https://bsnk.exmaple.nl/kr/activate" Binding="http://schemas.xmlsoap.org/soap/http" />
        <md:NameIDMappingService Location="https://bsnk.exmaple.nl/kr/tranform" Binding="http://schemas.xmlsoap.org/soap/http" />
    </md:IDPSSODescriptor>
    <md:Organization>
        <md:OrganizationName xml:lang="nl">Voorbeeld BSNk</md:OrganizationName>
        <md:OrganizationDisplayName xml:lang="nl">Voorbeeld BSNk</md:OrganizationDisplayName>
        <md:OrganizationURL xml:lang="nl">https://bsnk.example.nl/</md:OrganizationURL>
    </md:Organization>
    <md:ContactPerson contactType="technical">
        <md:SurName>BSNk koppelregister</md:SurName>
        <md:EmailAddress>koppelregister@bsnk.example.nl</md:EmailAddress>
        <md:TelephoneNumber>+31-10-1234567</md:TelephoneNumber>
    </md:ContactPerson>
</md:EntityDescriptor>

The BSNk as Key Management Authority MUST publish its details as an SPSSODescriptor. The AssertionConsumerEndpoint element MUST contain the endpoint for obtaining Dienstverlener keys (AUC10 Verstrekken sleutelmateriaal Dienstverleners).

The EntityDescriptor of the Sleutelbeheerder MUST contain an AdditionalMetadataLocation element, containing the location where the Autorisatielijst BSN can be obtained.

Example SleutelBeheer EntityDescriptor

XML

<md:EntityDescriptor entityID="urn:nl-gdi-eid:entity:99999999012345670000"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">

    <md:SPSSODescriptor WantAssertionsSigned="true" AuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <md:KeyDescriptor use="signing">
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>...</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </md:KeyDescriptor>
        <md:NameIDFormat>urn:nl-gdi-eid:1.0:id:Pseudonym</md:NameIDFormat>
        <md:AssertionConsumerService Location="https://bsnk.example.nl/keymgmt/dv/key-request" index="1" isDefault="true" Binding="http://schemas.xmlsoap.org/soap/http" />
    </md:SPSSODescriptor>
    <md:Organization>
        <md:OrganizationName xml:lang="nl">Voorbeeld BSNk</md:OrganizationName>
        <md:OrganizationDisplayName xml:lang="nl">Voorbeeld BSNk</md:OrganizationDisplayName>
        <md:OrganizationURL xml:lang="nl">https://bsnk.example.nl/</md:OrganizationURL>
    </md:Organization>
    <md:ContactPerson contactType="technical">
        <md:SurName>BSNk sleutelbeheer</md:SurName>
        <md:EmailAddress>sleutelbeheer@bsnk.example.nl</md:EmailAddress>
        <md:TelephoneNumber>+31-10-1234567</md:TelephoneNumber>
    </md:ContactPerson>
</md:EntityDescriptor>

WantAuthnRequestsSigned

An IDPSSODescriptor element MUST contain the WantAuthnRequestsSigned XML attribute with value "true" and MUST NOT contain any other optional attributes. An SPSSODescriptor element MUST contain the AuthnRequestsSigned XML attribute with value "true" and a WantAssertionsSigned XML attribute with value "true" and MUST NOT contain any other optional attributes.

NameIDFormat

An IDPSSODescriptor element MUST contain one or more NameIDFormat XML attribute(s), containing the Identificerende kenmerken (EntityConcernedTypes) the participant supports. A SPSSODescriptor of a Participant (as used by HM) MUST NOT contain a NameIDFormat.

The following NameIDFormats should be included per role, if certified for the applicable domain (and conditions):

Role	Application domain	Additional condition	include NameIDFormat
HM	*Citizen domain	eHerkenning branding	urn:etoegang:1.12:EntityConcernedID:PseudoID urn:etoegang:1.12:EntityConcernedID:BSN
	Consumer domain	eHerkenning branding	urn:etoegang:1.9:EntityConcernedID:Pseudo urn:etoegang:1.12:EntityConcernedID:PseudoID
	Business domain	eHerkenning branding	urn:etoegang:1.9:EntityConcernedID:KvKnr urn:etoegang:1.9:EntityConcernedID:RSIN urn:etoegang:1.13:EntityConcernedID:PROBASnr urn:etoegang:1.13:EntityConcernedID:TRR-BD
AD	Consumer domain	eHerkenning branding	urn:etoegang:1.9:EntityConcernedID:Pseudo urn:etoegang:1.12:EntityConcernedID:PseudoID
	Business domain	eHerkenning branding	urn:etoegang:1.9:EntityConcernedID:KvKnr urn:etoegang:1.9:EntityConcernedID:RSIN urn:etoegang:1.13:EntityConcernedID:PROBASnr urn:etoegang:1.13:EntityConcernedID:TRR-BD
MR	Business domain	eHerkenning branding; KvKnr supported	urn:etoegang:1.9:EntityConcernedID:KvKnr
		eHerkenning branding; RSIN nummer supported	urn:etoegang:1.9:EntityConcernedID:RSIN
		eHerkenning branding; PROBASnr supported eHerkenning branding; TRR-BD supported	urn:etoegang:1.13:EntityConcernedID:PROBASnr urn:etoegang:1.13:EntityConcernedID:TRR-BD
		eHerkenning branding; KvKnr + chain authorization supported	urn:etoegang:1.9:IntermediateEntityID:KvKnr
		eHerkenning branding; RSIN nummer chain authorization supported	urn:etoegang:1.9:IntermediateEntityID:RSIN
EB	*Citizen domain	eHerkenning branding	urn:etoegang:1.12:EntityConcernedID:BSN urn:etoegang:1.12:EntityConcernedID:PseudoID
	Consumer domain	eHerkenning branding	urn:etoegang:1.9:EntityConcernedID:Pseudo
	Business domain	eHerkenning branding	urn:etoegang:1.11:EntityConcernedID:eIDASLegalIdentifier

*Citizen domein: only voor EU Citizens

Example NameIDFormat

XML

...
<md:IDPSSODescriptor>
    ...
	<md:NameIDFormat>urn:etoegang:1.9:EntityConcernedID:KvKnr</md:NameIDFormat>
	<md:NameIDFormat>urn:etoegang:1.9:EntityConcernedID:Pseudo</md:NameIDFormat>
    ...
</md:IDPSSODescriptor>
...

KeyDescriptor

An IDPSSODescriptor, SPSSODescriptor or AttributeAuthorityDescriptor element MUST contain one or more KeyDescriptor elements with the use XML attribute with value "signing". The IDPSSODescriptor of a MR or the AttributeAuthorityDescriptor of a KR MUST contain at least one or more KeyDescriptor with the use XML attribute with value "encryption". Alternatively, at least one KeyDescriptor without a use XML attribute MAY be included, indicating the default that the key is for both signing and encryption. Every KeyDescriptor element marked for "signing" MUST contain a KeyName element and a valid PKIoverheid certificate with which the participant's SAML messages and/or direct TLS connections can be authenticated. KeyDescriptors marked for "signing" MAY contain valid certificates for authenticating direct TLS connections that are not PKIoverheid, as long as they comply with the requirements in Secure connection. Every KeyDescriptor element marked for "encryption" MUST contain a KeyName element and a valid PKIoverheid certificate for encrypting IDs and attributes for that participant.

In case a role is a source or recipient for Polymorphic Pseudonyms (or Polymorphic Identities), this roles has one or more PP-scheme specific keys. These keys are versioned, to allow for key-management.

A role MAY have one or more versions of PP-KeySet in use. In case no version is specified, the default value "1" is to be used as keyset version. In case multiple KeySetVersions are listed, one MUST be marked as"default".

Additional KeyDescriptor elements without specificied "use" attribute MAY be included, to describe (derived) keys used in the Polymorphic Pseudonymzation algorithm. These KeyDescriptor MUST contain a KeyInfo element, with a KeyName element using 'urn:nl-gdi-eid:1.0:pp-key:<Environment>:<SchemeKeySetVersion>:<KeyName>:<KeyVersion>' to describe the key. In case of public keys, these MUST be included as KeyValue element using a ECKeyValue and a NamedCurve with PublicKey (NOTE: ECKeyValue is specified in XML-signature 1.1). In case of derived keys, other elements MUST NOT be included.

Note

Service providers and participants MUST process all of the described KeyDescriptor elements. KeyName in the signatures and protocol messages indicates which certificate in the metadata is used for the signature.

Example KeyDescriptor

XML

...
<md:KeyDescriptor>
    <ds:KeyInfo>
        <ds:KeyName>urn:nl-gdi-eid:1.0:pp-key:test:1:AA_D99999999012345670000:1</ds:KeyName>
    </ds:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor>
    <ds:KeyInfo>
        <!-- PIP/PP/PI public signing key for BSNk-activate in test network -->
        <ds:KeyName>urn:nl-gdi-eid:1.0:pp-key:test:1:U:1</ds:KeyName>
            <ds:KeyValue>
            <ds11:ECKeyValue>
                <!-- brainpool P320r1 curve -->
                <ds11:NamedCurve URI="urn:oid:1.3.36.3.3.2.8.1.1.9"/>
                <ds11:PublicKey>
                   MQo=...
                </ds11:PublicKey>
            </ds11:ECKeyValue>
        </ds:KeyValue>
    </ds:KeyInfo>
</md:KeyDescriptor>
...

To indicate whether to receive an internal pseudonym or persistent pseudonym, the MR MUST supply a UserTypeRequested in the metadata: InternalPseudonym for the internal pseudonym, PseudoID for the Encrypted Pseudonym.

See examples: Example 3 - example metadata extension.xml and XML schema metadata extension.1.13.xsd