Difference between revisions of "Federation"
From MgmtWiki
(→Problem) |
m (→Other Material) |
||
| (15 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | Wherever a collection of [[ | + | Wherever a collection of [[Provider]]s or [[Relying Party|Relying Parties]] band together to create a common set of rules that all agree to be bound by. |
| + | |||
==Context== | ==Context== | ||
| − | Federation allow the creation of | + | * Federation originated in the ''foederati'' states that were supported by the Roman Empire in lands bordering the empire. "Less expensive and more efficient in operation, the ''foederati'' ultimately became independent rulers of the borderlands, with their interests intersecting in many ways with the policy of their imperial superiors.<ref>Marcin Grodzki, ''Yeuda D. Nevo'' Rocznik Orientalistyczny, vol. LXXI, issue 1, 2018, pp. 55–95</ref> |
| + | * The strength of the central authority in a federation is the subject of huge debate, but eventually no conclusion other than practical necessity. | ||
| + | * Federation allow the creation of an [[Identifier]]. [[Ecosystem]] to be implemented for the imposition of policies that apply to all members of the federation. | ||
| + | * None of this is ever for the benefit of the user. The best we can hope for is that it will do no new harms. Incidentally [[Federation]] might reduce the cognitive load on the user, which is also to the benefit of the web site. | ||
==Problem== | ==Problem== | ||
| Line 9: | Line 13: | ||
==Solution== | ==Solution== | ||
In order that a [[Federation]] can expose both is principles and its membership to the public a [[Federation Trust Repository]] must be maintained and [[Trust]]ed by users of the [[Federation]]. | In order that a [[Federation]] can expose both is principles and its membership to the public a [[Federation Trust Repository]] must be maintained and [[Trust]]ed by users of the [[Federation]]. | ||
| − | * [https://openid.net/specs/openid-connect-federation-1_0.html OpenID Connect Federation 1.0 - draft | + | * [https://openid.net/specs/openid-connect-federation-1_0.html OpenID Connect Federation 1.0 - current draft] <blockquote>The OpenID Connect standard specifies how a Relying Party (RP) can discover metadata about an OpenID Provider (OP), and then register to obtain RP credentials. The [[Provider Discovery]] and registration process does not involve any mechanisms of dynamically establishing trust in the exchanged information, but instead rely on out-of-band trust establishment. In an identity federation context, this is not sufficient. The participants of the federation must be able to trust information provided about other participants in the federation. OpenID Connect Federations specifies how trust can be dynamically obtained by resolving trust from a common trusted third party.</blockquote> |
| + | * A [[Self-issued OpenID Provider]]<blockquote> can be make to work for a [[Relying Party]] by federating ID Providers behind a single like that can be displayed on the RP directing the user to a [[Self-issued OpenID Picker]], also known as a Chooser.</blockquote> | ||
==References== | ==References== | ||
<references /> | <references /> | ||
| + | ===Other Material=== | ||
* [https://www.nist.gov/publications/nist-cloud-federation-reference-architecture The NIST Cloud Federation Reference Architecture] | * [https://www.nist.gov/publications/nist-cloud-federation-reference-architecture The NIST Cloud Federation Reference Architecture] | ||
| − | [[Category:Glossary]] | + | [[Category: Glossary]] |
| − | [[Category:Trust]] | + | [[Category: Trust]] |
| + | [[Category: Federation]] | ||
Latest revision as of 11:49, 3 July 2022
Full Title or Meme
Wherever a collection of Providers or Relying Parties band together to create a common set of rules that all agree to be bound by.
Context
- Federation originated in the foederati states that were supported by the Roman Empire in lands bordering the empire. "Less expensive and more efficient in operation, the foederati ultimately became independent rulers of the borderlands, with their interests intersecting in many ways with the policy of their imperial superiors.[1]
- The strength of the central authority in a federation is the subject of huge debate, but eventually no conclusion other than practical necessity.
- Federation allow the creation of an Identifier. Ecosystem to be implemented for the imposition of policies that apply to all members of the federation.
- None of this is ever for the benefit of the user. The best we can hope for is that it will do no new harms. Incidentally Federation might reduce the cognitive load on the user, which is also to the benefit of the web site.
Problem
- Most Identity Management systems are constructed to work with a range of publicly accessible sites that do not have all of the security protections that are required in high value transactions.
Solution
In order that a Federation can expose both is principles and its membership to the public a Federation Trust Repository must be maintained and Trusted by users of the Federation.
- OpenID Connect Federation 1.0 - current draft
The OpenID Connect standard specifies how a Relying Party (RP) can discover metadata about an OpenID Provider (OP), and then register to obtain RP credentials. The Provider Discovery and registration process does not involve any mechanisms of dynamically establishing trust in the exchanged information, but instead rely on out-of-band trust establishment. In an identity federation context, this is not sufficient. The participants of the federation must be able to trust information provided about other participants in the federation. OpenID Connect Federations specifies how trust can be dynamically obtained by resolving trust from a common trusted third party.
- A Self-issued OpenID Provider
can be make to work for a Relying Party by federating ID Providers behind a single like that can be displayed on the RP directing the user to a Self-issued OpenID Picker, also known as a Chooser.
References
- ↑ Marcin Grodzki, Yeuda D. Nevo Rocznik Orientalistyczny, vol. LXXI, issue 1, 2018, pp. 55–95
