...
- The layout of the existing specifications should be adopted significantly to allow for incorporating new protocols.
- Many sections, even if these do not specifically reference an implementation, make use of SAML specific jargon. This includes the name of the thing itself: an Entity Category is defined in the SAML specification.
The OIDC specification supports the concept of contact details, but only as a simple multivalued list of email adresses. In the SAML version of the specification a more fine grained methodology is used, where technical, administrative and support contact details are identifiable. To resolve this issue, the proposal in github suggests a new claim, "contacts_detailed", supports the same granularity as is used in the SAML implementation of the specification.
The use of entity labels, "Trustmarks" in OpenID Federation, is subject to specific rules as layed out in the OID Fed specification. As such it is not possible to have the same Trustmark exist both as a self-issued and at the same time as a trustmark issued by a trustmark issuer, which is what the current specification suggests (SPs and IdP may both publish support for the entity category, however the SP version is veted by FedOps, whereas the IdP version is self issued). This might lead to the need to have different trustmark identifiers per protocol. This is probable not optimal as it may lead to ambiguity in the implementation of the same specification between protocols.
- OpenID Federation has a well developed mechanism to delegate the issuance and ownership of Trustmarks. These capabilities may allow REEFDs to be owner of the relevant Trustmarks without the need to implement a techncial infrastructure which would have to be part of the actual authentication transactions.
- Is seems like a good idea to include the definition of a personalized scope to streamline the exchange of personal data
...