Difference between revisions of "Federation Trust Registry"
From MgmtWiki
(→Solution) |
(→Is it Trustworthy) |
||
| (96 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | Wherever a [[Web Site]]s wishes to take advantage of the benefits of belonging to a [[Federation]] it needs to be exposed in a Data Service that allows any user to ensure that the [[Web Site]] has been [[Validated]] by the [[Federation]]. | + | Wherever a [[Web Site]]s wishes to take advantage of the benefits of belonging to a [[Federation]] it needs to be exposed in a Data Service that allows any user to ensure that the [[Web Site]] has been [[Validated]] by the [[Federation]], or, at the very least, subscribed to the federation's principles. |
==Context== | ==Context== | ||
| − | Several variations on the theme of a [[Federation Trust Registry]] exist already. | + | * While an early [[Federation Trust Registry]] would likely just list federation members and provide a logo to display on the member's site, now a Trust Registry is expected to provide a service API that can respond to requests about members with an [[Entity Statement]]. |
| + | * As more and more governments and organization start to talk about building a [[Trust Registry]]<rev>Digital Identity Laboratory, ''Trust Registry'' Canadian Internet Registration Authority (CIRA) https://www.idlab.org/wp-content/uploads/2022/06/Executive-Summary-CIRA-Trust-Registry.pdf</ref> the more it becomes clear that Federation now means no more, and no less, than an application level [[Identifier]] trust ecosystem. | ||
| + | Several variations on the theme of a [[Federation Trust Registry]] exist already. But it must be noted that the only function that a federation needs to perform is the creation and administration of the rules for registering an entity with the Trust Registry. | ||
* [http://www.tscp.org/trust-framework-services/ Trust Services] of TSCP the Transglobal Secure Collaboration Program (mostly focused on NATO A&D industry). | * [http://www.tscp.org/trust-framework-services/ Trust Services] of TSCP the Transglobal Secure Collaboration Program (mostly focused on NATO A&D industry). | ||
| − | * UK Open Banking (focused on UK banks and payment processors) | + | * UK Open Banking (focused on UK banks and payment processors) Trust Registry is run by the [https://www.openbanking.org.uk/news/the-obie-responds-to-the-fcas-open-finance-call-for-input/ FCA]. |
* Recognized Coordinating Entity (RCE) (focused on the US Health Care community.)<ref name='tefca'>The Office of the National Coordinator (ONC) for Health Information Technology, ''DRAFT TRUSTED EXCHANGE FRAMEWORK.'' (2018) Section 2 - How Will it Work p. 9ff https://www.healthit.gov/sites/default/files/draft-trusted-exchange-framework.pdf </ref> See the page on [[TEFCA]]. | * Recognized Coordinating Entity (RCE) (focused on the US Health Care community.)<ref name='tefca'>The Office of the National Coordinator (ONC) for Health Information Technology, ''DRAFT TRUSTED EXCHANGE FRAMEWORK.'' (2018) Section 2 - How Will it Work p. 9ff https://www.healthit.gov/sites/default/files/draft-trusted-exchange-framework.pdf </ref> See the page on [[TEFCA]]. | ||
| − | When a US | + | When a US federal agency's mission requires that it disseminate controlled unclassified information ([[CUI]]) to non-executive branch entities, but prohibits it from entering into a contractual arrangement, the agency is nevertheless directed to seek the entity's protection of [[CUI]] in accordance with [https://obamawhitehouse.archives.gov/the-press-office/2010/11/04/executive-order-13556-controlled-unclassified-information Executive Order 13556], Controlled Unclassified Information, or any successor order, and the [[CUI]] Program regulations, which include requirements to comply with [https://csrc.nist.gov/publications/detail/sp/800-171/rev-1/archive/2016-12-20 NIST SP 800-171]. |
| + | |||
| + | Standards must be implemented, potentially with a profile, to ensure that the result is "as consistently as possible, follows implementation guides and authoritative best practices published by the applicable standards development organization (SDO). Minimizing variation in how standards are implemented will make it easier for others to connect to Electronic Health Information. Further, to the extent possible, Electronic Health Information stored in health IT products should be structured and coded using standardized vocabularies."<ref name='tefca'></ref> | ||
==Problem== | ==Problem== | ||
| − | So far every solution has been one-off and not applicable to the next federation with the same general problem. | + | *Users and participants in an [[Identity]] Federation need to understand in real-time whether any particular web site is conformant with federation rules. Or, in other words, the user must be aware of the rules that apply to their current activity. |
| + | *So far, every solution has been one-off and not applicable to the next federation with the same general problem. | ||
| + | * Most user's experience with [[Internet Security]] is sub-optimal or worse. Trust Registries might be able to address at least some of the security challenges. | ||
| + | * More and more protocols developers have realized that they need Trust Registries without understanding that trust cannot be measured without the policies that have here-to-fore been generated by the federation. In other words, the rule set must exist before trust can be quantified in a registry. Unfortunately, those developers and architects have started to build the registries before the rules are in place. This is worse than a waste of time, it creates a format for registries before we understand what data needs to be in those registries. | ||
| + | |||
| + | ===Is it Trustworthy=== | ||
| + | * There are schemes afoot across the globe by governments and organizations like [[Trust Over IP]]. Evidence in 2022 is that the registries are not, in fact, trustworthy.<ref>Carsten Maple ''Exploring over-reliance on blind trust in digital IDs'' The Alan Turing Institute (2021-05-26) https://www.turing.ac.uk/blog/exploring-over-reliance-blind-trust-digital-ids</ref> | ||
| + | * Can users get any signals from the federation that their interests are being supported?<blockquote>The [https://openid.net/specs/openid-connect-federation-1_0-28.html current OpenID federation spec] (2023-12) is designed to support the entities in the federation. While a Trustmark can be displayed to the user of one of federation's members with a link to some site, there is no way for the user to be sure of the actually identity of the site displaying the mark.</blockquote> | ||
| + | |||
| + | ===Regulation and Liability=== | ||
| + | Just like [[Identifier or Attribute Provider]]s, any site that provides trust metadata could be liable if the recommendations turn out to be misleading and the user suffers a loss as a result. | ||
| + | |||
| + | One way to avoid [[Liability]] is for a sovereign state to require that some trust Registry must be accepted. The major problem with that is that means that security of the web would move at the speed of regulation, which is insufficient to keep the web secure.<ref>Vint Cerf, ''Concerns Regarding the Revised Article 45 of e-ID Draft Legislative Proposal'' https://storage.googleapis.com/gweb-uniblog-publish-prod/documents/Re__Concerns_the_Revised_Article_45_of_e-ID_Draft_Legislative_Proposal_xbnJTci.pdf</ref> While the particular problem described by Vint Cerf may not survive into EU law, the propensity of legislatures to mess with user's trust will surely continue to compromise the security of online commerce. See the wiki page "[[GDPR is a scam]]" for more examples. | ||
==Solution== | ==Solution== | ||
| + | There will be a Nationwide, or Global, registry of all compliant federations. That is able to answer queries about whether any [[Web Site]] is currently compliant. Queries can have specific site [[Identifier]]s or any character sting that will return a list of participants that meet the query. This services is specifically designed to be user friendly. This implies some sort of standard way to create a [[Trust Registry Identifier]] that can be photographically bound each [[Trust Registry]]. | ||
| + | |||
In order that a [[Federation]] can be expose both is principles and its membership to the public some data server needs to provide information about the existing membership and their status. There are two ways to do this: | In order that a [[Federation]] can be expose both is principles and its membership to the public some data server needs to provide information about the existing membership and their status. There are two ways to do this: | ||
#A list of the members and their status that can be viewed in a browser. | #A list of the members and their status that can be viewed in a browser. | ||
| Line 21: | Line 39: | ||
Of primary importance for a [[Federation]] that wants to allow user's to trust the members, is some easily accessible data service on a site that meets the following criteria<ref>Michael J. Carey +2, ''Data Services'' (2012-06) '''CACM 55''' No 6 Pp. 86-97</ref> | Of primary importance for a [[Federation]] that wants to allow user's to trust the members, is some easily accessible data service on a site that meets the following criteria<ref>Michael J. Carey +2, ''Data Services'' (2012-06) '''CACM 55''' No 6 Pp. 86-97</ref> | ||
# Reliable, always-on accessibility. | # Reliable, always-on accessibility. | ||
| − | # Meta-data descriptions of the contents of | + | # Meta-data descriptions of the contents of any federated [[Web Site]]. |
# Machine readable data as well as meta-data (called Service-Enabled Data Store). | # Machine readable data as well as meta-data (called Service-Enabled Data Store). | ||
# Data Security | # Data Security | ||
| + | # Contains no [[User Information]] and does not track the user, but is expected to respond [[Anonymous]]ly to [[User]] queries. | ||
| + | |||
| + | ===Federation Profile=== | ||
| + | Each federation will need to create their own set of specifications for determining those [[Web Site]]s and [[Subject]]s that may be registered. While that could be an independent effort, this page address those federations that define a [https://wiki.idesg.org/wiki/index.php/Framework_Profiles Framework Profile] of the IDEF registry. Only with a single rooted tree of registries can the user be sure of the source of trust. It is possible for the federation to break the [[Framework Profile]] into separate documents for security, privacy and interoperability as UK Open Banking did.<ref>''UK Open Banking OIDC Security Profile.'' https://bitbucket.org/openid/obuk/src/4630771db004da59992fb201641f5c4ff2c881f1/uk-openbanking-security-profile.md?at=master&fileviewer=file-view-default</ref> | ||
| + | |||
| + | Each federation will support one or more [[Federation API]]s that will enable any communicating [[Entity|Entities]] on the web to query the current status of each member. The [[Federation API]] page describes different sets of goals that depend on the purposes of the api, either technical or experiential. | ||
| + | |||
| + | ===Use Cases=== | ||
| + | *[https://wiki.idesg.org/wiki/index.php/Federated_Strong_Employee_ID Federated Strong Employee ID] | ||
| + | ===Working Sample Site=== | ||
| + | The work product can be viewed at [https://trustregistry.us this site]. | ||
| + | The Kantara demo registry can be viewed at [https://trustregistry.org this site]. It is currently focused on Healthcare apps. | ||
| + | |||
| + | ===Accreditation Services=== | ||
| + | For high assurance Trust Registries, some sort of [[Accreditation Service]] is required to evaluate the members to assurance compliance. | ||
| + | |||
| + | ===Fraunhofer=== | ||
| + | * [https://essif-lab.eu/essif-train-by-fraunhofer-gesellschaft EESIF Fraunhofer TRAIN project]<blockquote>Our component aims to extend the ESSIF-Framework through a global trust infrastructure that can be used to verify the trustworthiness of involved parties in an electronic transaction. The trust layer enables actors using the ESSIF-Framework to verify the root of trust of certificates used to sign credentials. In addition, the component allows for the definition, consideration, and verification of Trust Schemes compliance (e.g. eIDAS including LoAs or other Trust Schemes that can also be application/industry-specific) of involved parties. It is not dependent on a hierarchical CA infrastructure.</blockquote> | ||
| + | * [https://essif-lab.pages.grnet.gr/essif-lab/docs/open_calls/ EESIF open call] | ||
| + | * [https://essif-lab.github.io/framework eSSIF-Lab Framework] | ||
| + | |||
| + | Check out this link to a sample TRAIN Trust List , Isaac has provided: The trust-list can be found at the following link https://tspa.trust-scheme.de/tspa_train_domain/api/v1/scheme/test1-ehic-scheme.vc.train.trust-scheme.de. | ||
| + | |||
| + | ===Canada=== | ||
| + | Here is the line that seems to mean that holders are included in the Canadian [[Trust Registry]]. It could be that the line is poorly worded, but it seems to include holders in the process. "Digital Identity Ecosystems and their associated Trust Registries use a Trust Framework (such as the PCTF) to define how Issuers, Verifiers, Holders, and Digital Wallets should or must operate to be considered trustworthy." https://diacc.ca/trust-framework-components/pctf-trust-registries/ | ||
| + | ===Example Data Elements=== | ||
| + | The following is extracted from a representative collection of existing Trust Registries. Including those at the [https://gccn.axyom.co/gccn-registry-entries GCCN registry page.] | ||
| + | |||
| + | {|border="1" padding="2" width="799px" | ||
| + | | Element Name || OIDC || mdl || description | ||
| + | |- | ||
| + | |issuer || iss||VI||entity identifier of the issuer of the statement. If the iss and the sub are identical, the issuer is making a statement about itself. | ||
| + | |- | ||
| + | |Roles|| || || Need a formal taxonomy, e,g, Federation Trust Authority | ||
| + | |- | ||
| + | |jurisdiction|| || || Laws that apply, e.g. us-WA | ||
| + | |- | ||
| + | |Basis of trust|| || || Laws or other governance | ||
| + | |- | ||
| + | |subject || sub || DN|| The entity identifier of the subject | ||
| + | |- | ||
| + | |subjurl || sub || DN|| The URL of the subject, could be.a did or the common name from a cert | ||
| + | |- | ||
| + | |start date ||iat||nbf|| The time the statement was issued | ||
| + | |- | ||
| + | |end date || exp||naf|| The date/time the statement expires. | ||
| + | |- | ||
| + | |public key|| jwks|| cert ||the public part of the subject entity's signing keys. | ||
| + | |- | ||
| + | |recipient || aud|| ??|| audience | ||
| + | |- | ||
| + | |metadata|| metadata ||??|| metadata | ||
| + | |- | ||
| + | |policy|| metadata_policy||??|| policy | ||
| + | |- | ||
| + | |trust anchor|| trust_anchor_id ||??|| entity id | ||
| + | |- | ||
| + | |logos|| trust_mark ||??|| These logos can be displayed on the provider's web sites to allow informed user choice | ||
| + | |} | ||
| + | |||
| + | ===Submittter Data Elements=== | ||
| + | The following is extracted from a representative collection of existing Trust Registries. | ||
| − | + | {|border="1" padding="2" width="799px" | |
| + | | Element Name || OIDC || mdl || description | ||
| + | |- | ||
| + | nam|| iss||VI|| || e.g. submitter.corp.com | ||
| + | |- | ||
| + | |mail || || || Need a formal taxonomy, e,g, user@example.com | ||
| + | |- | ||
| + | |jurisdiction|| || || Laws that apply, e.g. us-WA | ||
| + | |- | ||
| + | |subjurl || sub || DN|| The URL of the submitter, could be.a did or the common name from a cert (optional) | ||
| + | |- | ||
| + | |public key|| jwks|| cert ||the public part of the subject entity's signing keys. (Optional) | ||
| + | |- | ||
| + | |metadata|| metadata ||??|| for example, president of company, etc. | ||
| + | |- | ||
| + | |trust anchor|| trust_anchor_id ||??|| entity id | ||
| + | |- | ||
| + | address|| |||| in the standard format name, strte, city, provide, country, potal code | ||
| + | |} | ||
==References== | ==References== | ||
| Line 31: | Line 129: | ||
===External Sources=== | ===External Sources=== | ||
| + | *[https://kantarainitiative.org/confluence/display/LC/Federation+Operator+Guidelines+%28FOG%29+v1.0 Kantara Initiative Federation Operators Guidelines] | ||
*OAuth 2.0 Dynamic Client Registration Protocol RFC 7591 | *OAuth 2.0 Dynamic Client Registration Protocol RFC 7591 | ||
*[https://www.ietf.org/mail-archive/web/oauth/current/msg18101.html Email thread that suggests use of software statements to provide federation]. | *[https://www.ietf.org/mail-archive/web/oauth/current/msg18101.html Email thread that suggests use of software statements to provide federation]. | ||
*Application Bridging for Federated Access Beyond Web (ABFAB) '''Use Cases''' RFC 7832. | *Application Bridging for Federated Access Beyond Web (ABFAB) '''Use Cases''' RFC 7832. | ||
| + | *[https://wiki.shibboleth.net/confluence/display/CONCEPT/Metadata Shibboleth Metadata] refers to configuration data used to provision an SP or IdP to communicate with each other. Typically, it exists in XML form, at least for publishing and interchange. | ||
| + | |||
| + | |||
| + | [[Category: Glossary]] | ||
| + | [[Category: Profile]] | ||
| + | [[Category: Liability]] | ||
| + | [[Category: Trust]] | ||
| + | [[Category: Federation]] | ||
Latest revision as of 20:15, 7 December 2023
Full Title or Meme
Wherever a Web Sites wishes to take advantage of the benefits of belonging to a Federation it needs to be exposed in a Data Service that allows any user to ensure that the Web Site has been Validated by the Federation, or, at the very least, subscribed to the federation's principles.
Context
- While an early Federation Trust Registry would likely just list federation members and provide a logo to display on the member's site, now a Trust Registry is expected to provide a service API that can respond to requests about members with an Entity Statement.
- As more and more governments and organization start to talk about building a Trust Registry<rev>Digital Identity Laboratory, Trust Registry Canadian Internet Registration Authority (CIRA) https://www.idlab.org/wp-content/uploads/2022/06/Executive-Summary-CIRA-Trust-Registry.pdf</ref> the more it becomes clear that Federation now means no more, and no less, than an application level Identifier trust ecosystem.
Several variations on the theme of a Federation Trust Registry exist already. But it must be noted that the only function that a federation needs to perform is the creation and administration of the rules for registering an entity with the Trust Registry.
- Trust Services of TSCP the Transglobal Secure Collaboration Program (mostly focused on NATO A&D industry).
- UK Open Banking (focused on UK banks and payment processors) Trust Registry is run by the FCA.
- Recognized Coordinating Entity (RCE) (focused on the US Health Care community.)[1] See the page on TEFCA.
When a US federal agency's mission requires that it disseminate controlled unclassified information (CUI) to non-executive branch entities, but prohibits it from entering into a contractual arrangement, the agency is nevertheless directed to seek the entity's protection of CUI in accordance with Executive Order 13556, Controlled Unclassified Information, or any successor order, and the CUI Program regulations, which include requirements to comply with NIST SP 800-171.
Standards must be implemented, potentially with a profile, to ensure that the result is "as consistently as possible, follows implementation guides and authoritative best practices published by the applicable standards development organization (SDO). Minimizing variation in how standards are implemented will make it easier for others to connect to Electronic Health Information. Further, to the extent possible, Electronic Health Information stored in health IT products should be structured and coded using standardized vocabularies."[1]
Problem
- Users and participants in an Identity Federation need to understand in real-time whether any particular web site is conformant with federation rules. Or, in other words, the user must be aware of the rules that apply to their current activity.
- So far, every solution has been one-off and not applicable to the next federation with the same general problem.
- Most user's experience with Internet Security is sub-optimal or worse. Trust Registries might be able to address at least some of the security challenges.
- More and more protocols developers have realized that they need Trust Registries without understanding that trust cannot be measured without the policies that have here-to-fore been generated by the federation. In other words, the rule set must exist before trust can be quantified in a registry. Unfortunately, those developers and architects have started to build the registries before the rules are in place. This is worse than a waste of time, it creates a format for registries before we understand what data needs to be in those registries.
Is it Trustworthy
- There are schemes afoot across the globe by governments and organizations like Trust Over IP. Evidence in 2022 is that the registries are not, in fact, trustworthy.[2]
- Can users get any signals from the federation that their interests are being supported?
The current OpenID federation spec (2023-12) is designed to support the entities in the federation. While a Trustmark can be displayed to the user of one of federation's members with a link to some site, there is no way for the user to be sure of the actually identity of the site displaying the mark.
Regulation and Liability
Just like Identifier or Attribute Providers, any site that provides trust metadata could be liable if the recommendations turn out to be misleading and the user suffers a loss as a result.
One way to avoid Liability is for a sovereign state to require that some trust Registry must be accepted. The major problem with that is that means that security of the web would move at the speed of regulation, which is insufficient to keep the web secure.[3] While the particular problem described by Vint Cerf may not survive into EU law, the propensity of legislatures to mess with user's trust will surely continue to compromise the security of online commerce. See the wiki page "GDPR is a scam" for more examples.
Solution
There will be a Nationwide, or Global, registry of all compliant federations. That is able to answer queries about whether any Web Site is currently compliant. Queries can have specific site Identifiers or any character sting that will return a list of participants that meet the query. This services is specifically designed to be user friendly. This implies some sort of standard way to create a Trust Registry Identifier that can be photographically bound each Trust Registry.
In order that a Federation can be expose both is principles and its membership to the public some data server needs to provide information about the existing membership and their status. There are two ways to do this:
- A list of the members and their status that can be viewed in a browser.
- A data service that exposes the contents of the site in machine readable format.
This page is about the later case.
Of primary importance for a Federation that wants to allow user's to trust the members, is some easily accessible data service on a site that meets the following criteria[4]
- Reliable, always-on accessibility.
- Meta-data descriptions of the contents of any federated Web Site.
- Machine readable data as well as meta-data (called Service-Enabled Data Store).
- Data Security
- Contains no User Information and does not track the user, but is expected to respond Anonymously to User queries.
Federation Profile
Each federation will need to create their own set of specifications for determining those Web Sites and Subjects that may be registered. While that could be an independent effort, this page address those federations that define a Framework Profile of the IDEF registry. Only with a single rooted tree of registries can the user be sure of the source of trust. It is possible for the federation to break the Framework Profile into separate documents for security, privacy and interoperability as UK Open Banking did.[5]
Each federation will support one or more Federation APIs that will enable any communicating Entities on the web to query the current status of each member. The Federation API page describes different sets of goals that depend on the purposes of the api, either technical or experiential.
Use Cases
Working Sample Site
The work product can be viewed at this site. The Kantara demo registry can be viewed at this site. It is currently focused on Healthcare apps.
Accreditation Services
For high assurance Trust Registries, some sort of Accreditation Service is required to evaluate the members to assurance compliance.
Fraunhofer
- EESIF Fraunhofer TRAIN project
Our component aims to extend the ESSIF-Framework through a global trust infrastructure that can be used to verify the trustworthiness of involved parties in an electronic transaction. The trust layer enables actors using the ESSIF-Framework to verify the root of trust of certificates used to sign credentials. In addition, the component allows for the definition, consideration, and verification of Trust Schemes compliance (e.g. eIDAS including LoAs or other Trust Schemes that can also be application/industry-specific) of involved parties. It is not dependent on a hierarchical CA infrastructure.
- EESIF open call
- eSSIF-Lab Framework
Check out this link to a sample TRAIN Trust List , Isaac has provided: The trust-list can be found at the following link https://tspa.trust-scheme.de/tspa_train_domain/api/v1/scheme/test1-ehic-scheme.vc.train.trust-scheme.de.
Canada
Here is the line that seems to mean that holders are included in the Canadian Trust Registry. It could be that the line is poorly worded, but it seems to include holders in the process. "Digital Identity Ecosystems and their associated Trust Registries use a Trust Framework (such as the PCTF) to define how Issuers, Verifiers, Holders, and Digital Wallets should or must operate to be considered trustworthy." https://diacc.ca/trust-framework-components/pctf-trust-registries/
Example Data Elements
The following is extracted from a representative collection of existing Trust Registries. Including those at the GCCN registry page.
| Element Name | OIDC | mdl | description |
| issuer | iss | VI | entity identifier of the issuer of the statement. If the iss and the sub are identical, the issuer is making a statement about itself. |
| Roles | Need a formal taxonomy, e,g, Federation Trust Authority | ||
| jurisdiction | Laws that apply, e.g. us-WA | ||
| Basis of trust | Laws or other governance | ||
| subject | sub | DN | The entity identifier of the subject |
| subjurl | sub | DN | The URL of the subject, could be.a did or the common name from a cert |
| start date | iat | nbf | The time the statement was issued |
| end date | exp | naf | The date/time the statement expires. |
| public key | jwks | cert | the public part of the subject entity's signing keys. |
| recipient | aud | ?? | audience |
| metadata | metadata | ?? | metadata |
| policy | metadata_policy | ?? | policy |
| trust anchor | trust_anchor_id | ?? | entity id |
| logos | trust_mark | ?? | These logos can be displayed on the provider's web sites to allow informed user choice |
Submittter Data Elements
The following is extracted from a representative collection of existing Trust Registries.
| Element Name | OIDC | mdl | description |
| Need a formal taxonomy, e,g, user@example.com | |||
| jurisdiction | Laws that apply, e.g. us-WA | ||
| subjurl | sub | DN | The URL of the submitter, could be.a did or the common name from a cert (optional) |
| public key | jwks | cert | the public part of the subject entity's signing keys. (Optional) |
| metadata | metadata | ?? | for example, president of company, etc. |
| trust anchor | trust_anchor_id | ?? | entity id |
References
- ↑ 1.0 1.1 The Office of the National Coordinator (ONC) for Health Information Technology, DRAFT TRUSTED EXCHANGE FRAMEWORK. (2018) Section 2 - How Will it Work p. 9ff https://www.healthit.gov/sites/default/files/draft-trusted-exchange-framework.pdf
- ↑ Carsten Maple Exploring over-reliance on blind trust in digital IDs The Alan Turing Institute (2021-05-26) https://www.turing.ac.uk/blog/exploring-over-reliance-blind-trust-digital-ids
- ↑ Vint Cerf, Concerns Regarding the Revised Article 45 of e-ID Draft Legislative Proposal https://storage.googleapis.com/gweb-uniblog-publish-prod/documents/Re__Concerns_the_Revised_Article_45_of_e-ID_Draft_Legislative_Proposal_xbnJTci.pdf
- ↑ Michael J. Carey +2, Data Services (2012-06) CACM 55 No 6 Pp. 86-97
- ↑ UK Open Banking OIDC Security Profile. https://bitbucket.org/openid/obuk/src/4630771db004da59992fb201641f5c4ff2c881f1/uk-openbanking-security-profile.md?at=master&fileviewer=file-view-default
External Sources
- Kantara Initiative Federation Operators Guidelines
- OAuth 2.0 Dynamic Client Registration Protocol RFC 7591
- Email thread that suggests use of software statements to provide federation.
- Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases RFC 7832.
- Shibboleth Metadata refers to configuration data used to provision an SP or IdP to communicate with each other. Typically, it exists in XML form, at least for publishing and interchange.
