Trustworthy Federation Registry API - Revision history

Tomjones: /* Solution */

2020-01-17T21:36:23Z

Solution

← Older revision		Revision as of 21:36, 17 January 2020
Line 15:		Line 15:
	**Note: that since the path component of a entity ID is not included when constructing the URL above, one API endpoint may serve as the federation API endpoint for several entities.		**Note: that since the path component of a entity ID is not included when constructing the URL above, one API endpoint may serve as the federation API endpoint for several entities.
	*The Federation API is an HTTPS API that may support multiple operations. Fetching entity statements is one of the operations, and the only one that all Federation API endpoints are REQUIRED to support. All the other operations are OPTIONAL. The list of defined operations may be extended in a future.		*The Federation API is an HTTPS API that may support multiple operations. Fetching entity statements is one of the operations, and the only one that all Federation API endpoints are REQUIRED to support. All the other operations are OPTIONAL. The list of defined operations may be extended in a future.
	*While all operations in the specification make use of a GET request, other operations may choose to use other HTTP methods. If the op parameter is left out, it is considered to be a fetch entity statements request. Unless otherwise agreed, requests to the federation API are not authenticated.		*While all operations in the specification make use of a GET request, other operations may choose to use other HTTP methods. If the op parameter is left out, it is considered to be a fetch entity statements request. Unless otherwise agreed, requests to the federation API are not authenticated. In other words any device on the web can access the entity statements of the endpoint. Of course that implies some sort of protection against denial of service attacks.
	*The Entity statement for each endpoint must contain the information needed to identify the role of the endpoint and to allow interoperation between the various endpoints in the federation.		*The Entity statement for each endpoint must contain the information needed to identify the role of the endpoint and to allow interoperation between the various endpoints in the federation.

Tomjones: /* Solution */

2020-01-17T21:34:44Z

Solution

← Older revision		Revision as of 21:34, 17 January 2020
Line 15:		Line 15:
	**Note: that since the path component of a entity ID is not included when constructing the URL above, one API endpoint may serve as the federation API endpoint for several entities.		**Note: that since the path component of a entity ID is not included when constructing the URL above, one API endpoint may serve as the federation API endpoint for several entities.
	*The Federation API is an HTTPS API that may support multiple operations. Fetching entity statements is one of the operations, and the only one that all Federation API endpoints are REQUIRED to support. All the other operations are OPTIONAL. The list of defined operations may be extended in a future.		*The Federation API is an HTTPS API that may support multiple operations. Fetching entity statements is one of the operations, and the only one that all Federation API endpoints are REQUIRED to support. All the other operations are OPTIONAL. The list of defined operations may be extended in a future.
			*While all operations in the specification make use of a GET request, other operations may choose to use other HTTP methods. If the op parameter is left out, it is considered to be a fetch entity statements request. Unless otherwise agreed, requests to the federation API are not authenticated.
	*The Entity statement for each endpoint must contain the information needed to identify the role of the endpoint and to allow interoperation between the various endpoints in the federation.		*The Entity statement for each endpoint must contain the information needed to identify the role of the endpoint and to allow interoperation between the various endpoints in the federation.

	While all operations in the specification make use of a GET request, other operations may choose to use other HTTP methods. If the op parameter is left out, it is considered to be a fetch entity statements request. Unless otherwise agreed, requests to the federation API are not authenticated.
	===Fetching Entity Statement (REQUIRED)===		===Fetching Entity Statement (REQUIRED)===
	Fetching entity statement is used to collect entity statements one by one in order to gather trust chains.		Fetching entity statement is used to collect entity statements one by one in order to gather trust chains.

Tomjones: /* Solution */

2020-01-17T21:33:46Z

Solution

← Older revision		Revision as of 21:33, 17 January 2020
Line 12:		Line 12:

	==Solution==		==Solution==
			*All entities that are expected to publish entity statements about themselves or other entities, MUST expose a Federation API endpoint. The federation API endpoint of an entity is resolved from the entity identifier. The Federation API endpoint is found using the Well known URIs specification, with the suffix openid-federation. The scheme, host and port is taken directly from the entity identifier combined with the following path: /.well-known/idef and followed by the specific endpoint name.
	All entities that are expected to publish entity statements about themselves or other entities, MUST expose a Federation API endpoint.		**Note: that since the path component of a entity ID is not included when constructing the URL above, one API endpoint may serve as the federation API endpoint for several entities.
	The federation API endpoint of an entity is resolved from the entity identifier. The Federation API endpoint is found using the Well known URIs specification, with the suffix openid-federation. The scheme, host and port is taken directly from the entity identifier combined with the following path: /.well-known/idef and followed by the specific endpoint name.		*The Federation API is an HTTPS API that may support multiple operations. Fetching entity statements is one of the operations, and the only one that all Federation API endpoints are REQUIRED to support. All the other operations are OPTIONAL. The list of defined operations may be extended in a future.
	Note that since the path component of a entity ID is not included when constructing the URL above, one API endpoint may serve as the federation API endpoint for several entities.		*The Entity statement for each endpoint must contain the information needed to identify the role of the endpoint and to allow interoperation between the various endpoints in the federation.
	The Federation API is an HTTPS API that may support multiple operations. Fetching entity statements is one of the operations, and the only one that all Federation API endpoints are REQUIRED to support. All the other operations are OPTIONAL. The list of defined operations may be extended in a future.

	While all operations in the specification make use of a GET request, other operations may choose to use other HTTP methods. If the op parameter is left out, it is considered to be a fetch entity statements request. Unless otherwise agreed, requests to the federation API are not authenticated.		While all operations in the specification make use of a GET request, other operations may choose to use other HTTP methods. If the op parameter is left out, it is considered to be a fetch entity statements request. Unless otherwise agreed, requests to the federation API are not authenticated.

Tomjones: /* Problems */

2020-01-17T21:23:43Z

Problems

← Older revision		Revision as of 21:23, 17 January 2020
Line 9:		Line 9:
	==Problems==		==Problems==
	# The user in an ID Ecosystem currently has limited resources to determine the validity and trustworthiness of the web sites visited or of the apps offered to allow authenticated access to websites in that federation.		# The user in an ID Ecosystem currently has limited resources to determine the validity and trustworthiness of the web sites visited or of the apps offered to allow authenticated access to websites in that federation.
	# In [[OpenID Connect 1.0]] it is assumed that the Identity Provider (IdP) and the Attribute Provider (AP) share the same information about the identity and consent of the user. In a federated environment this requires an additional level of abstraction between the IdP and the AP to accommodate the likenly differences in the identifiers used for the subject and other entities to the transaction.		# In [[OpenID Connect 1.0]] it is assumed that the Identity Provider (IdP) and the Attribute Provider (AP) share the same information about the identity and consent of the user. In a federated environment this requires an additional level of abstraction between the IdP and the AP to accommodate the likenly differences in the identifiers used for the subject and other entities to the transaction. Note that the AP is called the "Resource" in the OpenID specs and may provide access to other content than user attributes, but that is beyond the scope of this discussion.

	==Solution==		==Solution==

Tomjones: /* Problems */

2020-01-17T21:20:07Z

Problems

← Older revision		Revision as of 21:20, 17 January 2020
Line 9:		Line 9:
	==Problems==		==Problems==
	# The user in an ID Ecosystem currently has limited resources to determine the validity and trustworthiness of the web sites visited or of the apps offered to allow authenticated access to websites in that federation.		# The user in an ID Ecosystem currently has limited resources to determine the validity and trustworthiness of the web sites visited or of the apps offered to allow authenticated access to websites in that federation.
	# In [[OpenID Connect 1.0]] it is assumed that the Identity Provider (IdP) and the Attribute Provider (AP) share the same information about the identity and consent of the user. In a federated environment this requires an additional level of abstraction between the IdP and the AP.		# In [[OpenID Connect 1.0]] it is assumed that the Identity Provider (IdP) and the Attribute Provider (AP) share the same information about the identity and consent of the user. In a federated environment this requires an additional level of abstraction between the IdP and the AP to accommodate the likenly differences in the identifiers used for the subject and other entities to the transaction.

	==Solution==		==Solution==

Tomjones: /* Problems */

2020-01-17T21:18:03Z

Problems

← Older revision		Revision as of 21:18, 17 January 2020
Line 9:		Line 9:
	==Problems==		==Problems==
	# The user in an ID Ecosystem currently has limited resources to determine the validity and trustworthiness of the web sites visited or of the apps offered to allow authenticated access to websites in that federation.		# The user in an ID Ecosystem currently has limited resources to determine the validity and trustworthiness of the web sites visited or of the apps offered to allow authenticated access to websites in that federation.
	# In [[OpenID Connect]] it is assumed that the Identity Provider (IdP) and the Attribute Provider (AP) share the same information about the identity and consent of the user. In a federated environment this requires an additional level of abstraction between the IdP and the AP.		# In [[OpenID Connect 1.0]] it is assumed that the Identity Provider (IdP) and the Attribute Provider (AP) share the same information about the identity and consent of the user. In a federated environment this requires an additional level of abstraction between the IdP and the AP.

	==Solution==		==Solution==

Tomjones: /* Problem */

2020-01-17T21:16:55Z

Problem

← Older revision		Revision as of 21:16, 17 January 2020
Line 7:		Line 7:
	* Websites and apps can supply an entity statement issued by a Trust Registry and validate the currency of that validation with the Registry.		* Websites and apps can supply an entity statement issued by a Trust Registry and validate the currency of that validation with the Registry.

	==~~Problem~~==		==Problems==
	* The user in an ID Ecosystem currently has limited resources to determine the validity and trustworthiness of the web sites visited or of the apps offered to allow authenticated access to websites in that federation.		# The user in an ID Ecosystem currently has limited resources to determine the validity and trustworthiness of the web sites visited or of the apps offered to allow authenticated access to websites in that federation.
			# In [[OpenID Connect]] it is assumed that the Identity Provider (IdP) and the Attribute Provider (AP) share the same information about the identity and consent of the user. In a federated environment this requires an additional level of abstraction between the IdP and the AP.

	==Solution==		==Solution==

Tomjones: /* References */

2020-01-16T00:42:08Z

References

← Older revision		Revision as of 00:42, 16 January 2020
Line 117:		Line 117:

	==References==		==References==
	*This specification was ~~drived~~ from [https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.5.1.2 The OpenID Connect Federation spec] (draft 10) and other documents, some of which are included below.		* This specification was derived from [https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.5.1.2 The OpenID Connect Federation spec] (draft 10) and other documents, some of which are included below.
	* The HL7 FHIR [http://hl7.org/fhir/smart-app-launch/scopes-and-launch-context/index.html plication Launch Framework Implementation Guide Release 1.0.0] was used to ensure that its needs were met.		* The HL7 FHIR [http://hl7.org/fhir/smart-app-launch/scopes-and-launch-context/index.html plication Launch Framework Implementation Guide Release 1.0.0] was used to ensure that its needs were met.

	[[Category:Profile]]		[[Category:Profile]]

Tomjones: /* References */

2020-01-16T00:41:42Z

References

← Older revision		Revision as of 00:41, 16 January 2020
Line 117:		Line 117:

	==References==		==References==
	*This specification was drived from [https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.5.1.2 The OpenID Connect Federation spec] (draft 7) and other documents, some of which are included below.		*This specification was drived from [https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.5.1.2 The OpenID Connect Federation spec] (draft 10) and other documents, some of which are included below.
	* The HL7 FHIR [http://hl7.org/fhir/smart-app-launch/scopes-and-launch-context/index.html plication Launch Framework Implementation Guide Release 1.0.0] was used to ensure that its needs were met.		* The HL7 FHIR [http://hl7.org/fhir/smart-app-launch/scopes-and-launch-context/index.html plication Launch Framework Implementation Guide Release 1.0.0] was used to ensure that its needs were met.

	[[Category:Profile]]		[[Category:Profile]]

Tomjones: /* Problem */

2020-01-16T00:41:05Z

Problem

← Older revision		Revision as of 00:41, 16 January 2020
Line 8:		Line 8:

	==Problem==		==Problem==
	* The user ~~of a~~ ID Ecosystem currently has limited resources to determine the validity and trustworthiness of the web sites visited or of the apps offered to allow authenticated access to websites in that federation.		* The user in an ID Ecosystem currently has limited resources to determine the validity and trustworthiness of the web sites visited or of the apps offered to allow authenticated access to websites in that federation.

	==Solution==		==Solution==