Difference between revisions of "Notary Seal"

From MgmtWiki
Jump to: navigation, search
(→‎Preconditions)
(→‎Preconditions)
Line 22: Line 22:
 
* Person with a cell phone that is loaded with a wallet app that can hold a credential which will allow access to the venue.
 
* Person with a cell phone that is loaded with a wallet app that can hold a credential which will allow access to the venue.
 
* Note that the exact method used for access can be radios or visual displays. This use case will describe the use of visual display of a QR code for convenience only. Any presentation media that meets the same ease of access would be acceptable. The QR code has the advantage that it can be presented on a smartphone or printed on a sheet of paper for those without smartphones.
 
* Note that the exact method used for access can be radios or visual displays. This use case will describe the use of visual display of a QR code for convenience only. Any presentation media that meets the same ease of access would be acceptable. The QR code has the advantage that it can be presented on a smartphone or printed on a sheet of paper for those without smartphones.
−
* The person, at home, wishes to acquire an access token that will allow then, when and where presented, access to a desired resource.
+
* The person, at home, wishes to acquire an access token with a [[Notary Seal]] that will allow them, when and where presented, access to a desired resource.
 
* While access to alcoholic beverages could talk place at several access points, for the purposes of this use case, it is assumed that every person with access to the private boxes is verified to be 21 so that a single access point get access to both the physical location, as well as the alcoholic beverages, in a manner similar to the "No person under 21 permitted beyond this point" rule.
 
* While access to alcoholic beverages could talk place at several access points, for the purposes of this use case, it is assumed that every person with access to the private boxes is verified to be 21 so that a single access point get access to both the physical location, as well as the alcoholic beverages, in a manner similar to the "No person under 21 permitted beyond this point" rule.
 
* A patron at a ballpark can wander around during the game with access points with many criteria so it will not be possible to determine in advance which access points a user might visit during the game. The approach taken here is to list all of the user claims that MIGHT BE required on the access token.
 
* A patron at a ballpark can wander around during the game with access points with many criteria so it will not be possible to determine in advance which access points a user might visit during the game. The approach taken here is to list all of the user claims that MIGHT BE required on the access token.

Revision as of 15:53, 13 November 2022

Full Title

This is a Use Case for the application of a a Notary Seal to a digital document.

Context

  • This use case considers the holder of a Wallet that has need to create high assurance transaction where some sort of face-to-face interaction is required.
  • The assumption is that face-to-face can be adequately simulated over a real-time communications connection between the Holder and the Notary.

Goal

To enable the creation of a single aggregated claim set that will will contain all of the credentials and attributes from the holder that are needed to complete one or more transactions.

Actors

  1. Holder seeking access to one (or more) game.
  2. Notary is used here to mean any person that has the authority to issue a seal that is required to make a transaction legal (or to make it defensible in a court of law).
  3. Validation web site that can analyze a person's access token remotely to let them know what access would be granted if used as specified by the relying party.
  4. Relying Party intake routine will need a collection of credentials and attributes that taken together give the required level of assurance to complete the transaction.

Note that the validation and relying party may, or may not, be the same Entity.

Preconditions

  • A state with strict rules about:
  1. minors access to alcoholic beverages. The only officially recognized digital proof of age is the state-issued driver's license or eID.
  2. Additional criteria like accreditation or health status for access to a venue or to take some action.
  • Person with a cell phone that is loaded with a wallet app that can hold a credential which will allow access to the venue.
  • Note that the exact method used for access can be radios or visual displays. This use case will describe the use of visual display of a QR code for convenience only. Any presentation media that meets the same ease of access would be acceptable. The QR code has the advantage that it can be presented on a smartphone or printed on a sheet of paper for those without smartphones.
  • The person, at home, wishes to acquire an access token with a Notary Seal that will allow them, when and where presented, access to a desired resource.
  • While access to alcoholic beverages could talk place at several access points, for the purposes of this use case, it is assumed that every person with access to the private boxes is verified to be 21 so that a single access point get access to both the physical location, as well as the alcoholic beverages, in a manner similar to the "No person under 21 permitted beyond this point" rule.
  • A patron at a ballpark can wander around during the game with access points with many criteria so it will not be possible to determine in advance which access points a user might visit during the game. The approach taken here is to list all of the user claims that MIGHT BE required on the access token.

Trigger

The person arriving at the access point with a cell phone containing the access token to be validated.

Scenarios

Primary Scenario:

  1. Holder is at a website that requires IAL2 identity assurance or higher for one particular transaction.

Secondary Scenario

  1. Holder us at a website that requires IALS identity assurance for a continuing series of transactions over time.

Successful Outcome

  1. The patron is able to present a access token at the main entrance and get through the metal detector with low hassle.
  2. Access checks at internal points can all be enabled with the same access token used at the main entrance.
  3. Where access is denied the patron can be informed of the required attribute that was not available in the token.

Unsuccessful Outcome

  1. Validity of the access token is tested by the patron before travel to the park. This is a better outcome that getting to the park and then being denied access, so it should be considered a partial success.
  2. Failure to access at main gate. The reason should be clear as a ticket counter available to get adjustments as required.

Privacy Concerns

  • The access token may contain more information that is required for the current visit.
  • Presence or lack of specific attributes in the token can be determine at any access point in the park.
  • The user attribute data is maintained at the park or at ticket-master for future use and is not well protected.
  • User has no simple means to tell the park or ticket-master to delete stored data.

Issues

  1. The patron is one of the 19% of the population w/o a smart phone. Perhaps her grandchild can help with that.
  2. Getting the wallet into the patron's smart phone or lap top may prove to be challenging.
  3. The patron is not comfortable with technology.
  4. Who determines what data from the MDL is sent to ticket-master, or the ball part? (e.g., the public health details or explicit user consent)?
  5. Is the driver's license ID number may be used for long term tracking of the user.?
  6. Is a picture required for patron matching to the person at the access points.
  7. Is fraud one of the threats to be addressed within the scope of the recommendation?

References

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Notary_Seal&oldid=16243"