Trust Federation Membership Validation - Revision history

Tomjones: /* Introduction */

2020-01-15T23:37:07Z

Introduction

← Older revision		Revision as of 23:37, 15 January 2020
Line 1:		Line 1:
	==Introduction==		==Introduction==

	This document lays out a method for doing get-requests for searching ~~the~~ IDEF Registry database. Searches can be done on services, companies, and service category. The method describes how people can determine the current membership of another digital entity in a Trust Framework, and find services in categories that matter to them.		This document lays out a method for doing get-requests for searching any IDEF Registry compatible database. Searches can be done on services, companies, and service category. The method describes how people can determine the current membership of another digital entity in a Trust Framework, and find services in categories that matter to them.

	These methods could be used together with a recommendation for adoption by the IDEF registry.		These methods could be used together with a recommendation for adoption by the Identity Ecosystem Framework (IDEF) registry.

	==Context==		==Context==

Tomjones: Tomjones moved page Trust Framework Membership Validation to Trust Federation Membership Validation: match industry naming trends

2020-01-15T23:34:52Z

Tomjones moved page Trust Framework Membership Validation to Trust Federation Membership Validation: match industry naming trends

← Older revision	Revision as of 23:34, 15 January 2020
(No difference)

Tomjones: /* Proposed formats for keys and identifiers */

2019-06-11T21:41:16Z

Proposed formats for keys and identifiers

← Older revision		Revision as of 21:41, 11 June 2019
Line 50:		Line 50:

	===Proposed formats for keys and identifiers===		===Proposed formats for keys and identifiers===
			For more details see the [[ID Ecosystem Framework API]] wiki page.

	The Trust Anchor end point MUST respond to queries with a list of all members matching the query with a key and at least one identifier. The format of the identity can be specified within the range listed below. The Trust Anchor or any service Provider would provide configuration information with a well-known URI (registered with the IETF) such as:		The Trust Anchor end point MUST respond to queries with a list of all members matching the query with a key and at least one identifier. The format of the identity can be specified within the range listed below. The Trust Anchor or any service Provider would provide configuration information with a well-known URI (registered with the IETF) such as:

Tomjones: /* Proposed formats for keys and identifiers */

2019-06-11T21:32:12Z

Proposed formats for keys and identifiers

← Older revision		Revision as of 21:32, 11 June 2019
Line 51:		Line 51:
	===Proposed formats for keys and identifiers===		===Proposed formats for keys and identifiers===

	The Trust Anchor end point MUST respond to queries with a list of all members matching the query with a key and at least one ~~identity~~. The format of the identity can be specified within the range listed below. The Trust Anchor or any service Provider would provide configuration information with a well-known URI (registered with the IETF) such as:		The Trust Anchor end point MUST respond to queries with a list of all members matching the query with a key and at least one identifier. The format of the identity can be specified within the range listed below. The Trust Anchor or any service Provider would provide configuration information with a well-known URI (registered with the IETF) such as:

	<nowiki>https://idesg.org/.wellknown/idesg-configuration</nowiki>		<nowiki>https://idesg.org/.wellknown/idesg-configuration</nowiki>

Tomjones: /* References and Coordination with other groups */

2019-05-21T17:57:34Z

References and Coordination with other groups

← Older revision		Revision as of 17:57, 21 May 2019
Line 223:		Line 223:
	[[Category:User Experience]]		[[Category:User Experience]]
	[[Category:Trust Framework]]		[[Category:Trust Framework]]
	[[Category:~~TFTM~~]]		[[Category:Profile]]

Tomjones: /* References and Coordination with other groups */

2018-11-25T17:07:05Z

References and Coordination with other groups

← Older revision		Revision as of 17:07, 25 November 2018
Line 220:		Line 220:
	*[https://github.com/TransparentHealth/poet Pre Oauth Entity Trust] describes a means to represent third-party application endorsement for health care applications. POET’s goal is to help consumers distinguish between applications that have an endorsement versus applications that have no pedigree (i.e untrusted and could be malicious).		*[https://github.com/TransparentHealth/poet Pre Oauth Entity Trust] describes a means to represent third-party application endorsement for health care applications. POET’s goal is to help consumers distinguish between applications that have an endorsement versus applications that have no pedigree (i.e untrusted and could be malicious).

			[[Category:Profile]]
	[[Category:User Experience]]		[[Category:User Experience]]
	[[Category:Trust Framework]]		[[Category:Trust Framework]]
	[[Category:TFTM]]		[[Category:TFTM]]

Tomjones: /* Browser Support */

2018-11-25T17:05:48Z

Browser Support

← Older revision		Revision as of 17:05, 25 November 2018
Line 47:		Line 47:

	===Browser Support===		===Browser Support===
	In (2018-09), Mozilla introduced a new service called Firefox Monitor that allows users to check whether their email addresses had been exposed as part of a data breach. Now, the company is adding a feature to its Firefox Quantum desktop browser that will alert people whenever they visit a site that has been breached in the last year.~~<ref>~~Dennis Fisher, (2018-11-15) https://duo.com/decipher/firefox-to-warn-users-when-they-visit-breached-sites~~</ref>~~		In (2018-09), Mozilla introduced a new service called Firefox Monitor that allows users to check whether their email addresses had been exposed as part of a data breach. Now, the company is adding a feature to its Firefox Quantum desktop browser that will alert people whenever they visit a site that has been breached in the last year. (reference Dennis Fisher, (2018-11-15) [https://duo.com/decipher/firefox-to-warn-users-when-they-visit-breached-sites Firefox to warn Users wen they visit Breached Sites.])

	===Proposed formats for keys and identifiers===		===Proposed formats for keys and identifiers===

Tomjones: /* Proposed formats for keys and identifiers */

2018-11-25T17:03:16Z

Proposed formats for keys and identifiers

← Older revision		Revision as of 17:03, 25 November 2018
Line 46:		Line 46:
	Create a web site for the Trust Anchor that can be queried using some part of the identifier. This site should allow search terms and return all of the identifiers that match the query. This step is required for proving membership in a Trust Framework, but is optional for digital entities that just wish to self-assert their identifier and policies. In an ideal world the policies should be machine readable as well as user understandable.		Create a web site for the Trust Anchor that can be queried using some part of the identifier. This site should allow search terms and return all of the identifiers that match the query. This step is required for proving membership in a Trust Framework, but is optional for digital entities that just wish to self-assert their identifier and policies. In an ideal world the policies should be machine readable as well as user understandable.

			===Browser Support===
			In (2018-09), Mozilla introduced a new service called Firefox Monitor that allows users to check whether their email addresses had been exposed as part of a data breach. Now, the company is adding a feature to its Firefox Quantum desktop browser that will alert people whenever they visit a site that has been breached in the last year.<ref>Dennis Fisher, (2018-11-15) https://duo.com/decipher/firefox-to-warn-users-when-they-visit-breached-sites</ref>
	===Proposed formats for keys and identifiers===		===Proposed formats for keys and identifiers===

Tomjones: /* The Solution */

2018-11-25T16:46:10Z

The Solution

← Older revision		Revision as of 16:46, 25 November 2018
Line 40:		Line 40:
	##The host name plus the port number plus the path. This is the method selected by the OpenID standards. It is very easy to confuse users with this choice.		##The host name plus the port number plus the path. This is the method selected by the OpenID standards. It is very easy to confuse users with this choice.
	#Use the public key of the SSL cert for the identity of the digital entity.		#Use the public key of the SSL cert for the identity of the digital entity.
	#The service provider creates a name (e.g. an [[URN]]), potentially localized but always with an ASCII representation, by which it would like to be known and uses that for registration to the [[Framework ~~Office~~]].		#The service provider creates a name (e.g. an [[URN]]), potentially localized but always with an ASCII representation, by which it would like to be known and uses that for registration to the [[#Framework Operator]].

	If the service wants to use an email address as an identifier for the digital entity to enable the user to contact the manufacturer, that should be permitted.		If the service wants to use an email address as an identifier for the digital entity to enable the user to contact the manufacturer, that should be permitted.

Tomjones: /* The Solution */

2018-11-25T16:41:37Z

The Solution

← Older revision		Revision as of 16:41, 25 November 2018
Line 40:		Line 40:
	##The host name plus the port number plus the path. This is the method selected by the OpenID standards. It is very easy to confuse users with this choice.		##The host name plus the port number plus the path. This is the method selected by the OpenID standards. It is very easy to confuse users with this choice.
	#Use the public key of the SSL cert for the identity of the digital entity.		#Use the public key of the SSL cert for the identity of the digital entity.
	#The service provider creates a name, potentially localized, by which it would like to be known.		#The service provider creates a name (e.g. an [[URN]]), potentially localized but always with an ASCII representation, by which it would like to be known and uses that for registration to the [[Framework Office]].

	If the service wants to use an email address as an identifier for the digital entity to enable the user to contact the manufacturer, that should be permitted.		If the service wants to use an email address as an identifier for the digital entity to enable the user to contact the manufacturer, that should be permitted.