<?xml version="1.0" encoding="UTF-8"?>
<registrierungtifoederation>
	<!--
		Typ des Föderationsteilnehmers.
		Gültiger Wert:  'Fachdienst'
	-->
	<teilnehmertyp>Fachdienst</teilnehmertyp>
	<!--
		Betriebsumgebung des Federation Master.
		Gültige Werte:  'RU', 'TU' oder 'PU'
	-->
	<betriebsumgebung>RU</betriebsumgebung>
	<!--
		E-Mail Adresse, unter welcher der Föderationsteilnehmer kontaktiert werden kann.
	-->
	<kontaktemail></kontaktemail>
	<!--
		Verfahrensschlüssel (der gematik-Zulassung) bei PU-Registrierung; sonst leer
	-->
	<vfsbestaetigung></vfsbestaetigung>
	<!--
		TI-ITSM-Zuweisungsgruppe des Fachdienst-Herstellers oder eines Vertreters.
		Kommt es zu Abweichungen der Registrierung, werden diese der hier hinterlegten Zuweisungsgruppe per Incident-Ticket(s) im TI-ITSM (ZIS) mitgeteilt.
	-->
	<zuweisungsgruppe>O-SVDGV:OR-ANBIntegDiGA</zuweisungsgruppe>
	<!--
		Eindeutige Identifikation des Föderationsteilnehmers innerhalb einer Betriebsumgebung.
		Die Member-ID wird durch gematik vergeben bzw. von gematik bekanntgegeben.
	-->
	<memberid></memberid>
	<!--
		Name der Organisation, die hinter dem Fachdienst steht.
		
		Gültige Werte:  gemäß Regex ^[ÄÖÜäöüß\w\ \-\.\&\+\*\/]{0,128}$
		Referenz im Entity Statement:
			* metadata.openid_relying_party.organization_name
	-->
	<organisationsname></organisationsname>
	<!--
		Name des Fachdienstes.
		
		Gültige Werte:  gemäß Regex ^[ÄÖÜäöüß\w\ \-\.\&\+\*\/]{1,128}$
		Referenz im Entity Statement:
			* metadata.federation_entity.name
			* metadata.openid_relying_party.client_name
			-> diese Werte müssen im Entity Statement zueinander identisch sein
	-->
	<fachdienstname></fachdienstname>
	<!--
		Adresse des Fachdienstes.
		Angabe ohne '/.well-known/openid-federation'
		Referenz im Entity Statement:
			* iss
	-->
	<fachdiensturi></fachdiensturi>
	<!--
		Keine oder mehrere OIDC-Scopes, die der Fachdienst verlangt.
		Entweder leer (<scopes/>) oder ein oder mehrere <scope>-Elemente unter <scopes>.
		Gültige Werte: Auswahl gemäß A_22989-01 [gemSpec_IDP_Sek]
		Referenz im Entity Statement:
			* metadata.openid_relying_party.scope
	-->
	<scopes>
		<scope>openid</scope>
		<!-- Beispiel für scope 'versicherter" -->
		<scope>urn:telematik:versicherter</scope>
	</scopes>
	<!--
		Keine oder mehrere Claims, die der Fachdienst verlangt.
		Entweder leer (<claims/>) oder ein oder mehrere <claim>-Elemente unter <claims>.
		Gültige Werte:  Auswahl gemäß A_22989-01 [gemSpec_IDP_Sek] oder beliebige weitere Claims
		Referenz im Entity Statement:
			* metadata.openid_relying_party.claims
	-->
	<!-- 
		aktuelle Empfehlung: keine claims nutzen und somit hier keine leeren Tags belassen;
		also am besten nutzen: <claims/> ohne Unterstruktur 
	-->

	<claims>
		<!-- Beispiel für claim 'id' -->
		<claim>urn:telematik:claims:id</claim>
		<claim>oder weiterer beliebiger Claim</claim>
	</claims>
	<!--
		Ein oder mehrere Redirect URLs, an welche die vom IDP ausgestellten Identitätsinformationen geschickt werden.
		Entweder leer (<redirect_uris/>) oder ein oder mehrere <redirect_uri>-Elemente unter <redirect_uris>.
		Referenz im Entity Statement:
			* metadata.openid_relying_party.redirect_uris
	-->
	<redirect_uris>
		<redirect_uri></redirect_uri>
	</redirect_uris>
	<!--
		Liste von ein oder mehreren Public Keys (PEM-Format) für JWT.
		Referenz im Entity Statement:
			* jwks.keys
	-->
	<publickeysjwt>
		<!-- Public Keys werden immer in einer `kid`- und `key`-Kombination bekannt gegeben. -->
		<publickey>
			<kid></kid>
			<key>
			-----BEGIN PUBLIC KEY-----
			....
			-----END PUBLIC KEY-----
			</key>
		</publickey>
	</publickeysjwt>
</registrierungtifoederation>
