Entity Statement: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
Line 1: Line 1:
==Full Title or Meme==
==Full Title or Meme==
An [[Attestation]] statement about the [[Trusted Identifier]] of the [[Entity]] typically from a [[Federation Operator]].
An [[Attestation]] statement about the [[Trusted Identifier]] of the [[Entity]] typically from a [[Federation Operator]].
==Preconditions==
* The primary use case for the [[Entity Statement]] is a user navigating to the web site where they need be able to trust the site with their [[User Private Information]].
==Problems==
* Best method for establishing trust with a web site today in the [[EV Cert]] which is designed to bind the web site to a real world entity.
==Solutions==
# Users can [[Authentication|Authenticate]] in a manner that gives a [[Relying Party]] a consistent [[Identifier]] that can be sued from session to session without the need for sharing any [[User Private Information]].
# To be fully compliant with the various [[Privacy]] legislation like the [[GDPR]] or the California legislation the [[Relying Party]] may first require that the user establish a channel back to the user for the performance of required [[Redress]] and [[Recovery]] operations.
# Only then should the [[Relying Party]] be in a position to request additional [[Attribute]]s from the [[User]].
==References==
*[https://www.federalregister.gov/documents/2018/11/14/2018-24714/developing-a-privacy-framework NIST Request for Information]
[[Category:Glossary]]
[[Category:Profile]]

Revision as of 21:25, 27 April 2019

Full Title or Meme

An Attestation statement about the Trusted Identifier of the Entity typically from a Federation Operator.

Preconditions

Problems

  • Best method for establishing trust with a web site today in the EV Cert which is designed to bind the web site to a real world entity.

Solutions

  1. Users can Authenticate in a manner that gives a Relying Party a consistent Identifier that can be sued from session to session without the need for sharing any User Private Information.
  2. To be fully compliant with the various Privacy legislation like the GDPR or the California legislation the Relying Party may first require that the user establish a channel back to the user for the performance of required Redress and Recovery operations.
  3. Only then should the Relying Party be in a position to request additional Attributes from the User.

References