Difference between revisions of "Notary Seal"
From MgmtWiki
(→Actors) |
(→References) |
||
| (22 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title== | ==Full Title== | ||
| − | This is a [[Use Case]] for the application of | + | This is a [[Use Case]] for the application of a [[Notary Seal]] to a digital document. |
==Context== | ==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. | * 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 | + | * The assumption is that the face-to-face requirement can be met by a real-time communications connection between the Holder and the Notary. |
===Goal=== | ===Goal=== | ||
| Line 11: | Line 11: | ||
===Actors=== | ===Actors=== | ||
# Holder seeking access to one (or more) game. | # Holder seeking access to one (or more) game. | ||
| − | # Notary is used here to mean | + | # Notary is used here to mean a notary public or other individual authorized to perform a notarial act as may be required for the acceptance of a digital document. |
| − | # | + | # Verification 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. |
# 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. | # 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]]. | + | * Note that the validation and relying party may, or may not, be the same [[Entity]]. |
| + | * Here notary may apply to a person that is actively involved in a real-time interactive transaction with the real-world human, or it may just be an [[Artificial Intelligence]] bot interacting with the human. In some cases the AI bot may be on the user's device or in the cloud. | ||
| + | |||
| + | ===Taxonomy=== | ||
| + | * Notary Seal = a verifiable digital indictor that a nortorial act has successful been preformed. | ||
| + | * Roles | ||
| + | # Basic Notarization of simple the presences and the intent of the signer with a hash of the document. The name of the document might be an optional field. | ||
| + | # Enhanced Notarization would include some evaluation of the form and complements of the document. It is not intended the this would go so far as to verification of the contents of the document. | ||
| + | |||
| + | ===Contents of a digital notary seal=== | ||
| + | # hash of doc notarized | ||
| + | # category of notary in this instance | ||
| + | # date and place notarized | ||
| + | # id of notary + things like dates and authority (this might be a credential all on its own) | ||
==Preconditions== | ==Preconditions== | ||
| − | * A state with strict rules about: | + | * A state with strict rules about (for example): |
| − | # | + | # Minors access to alcoholic beverages. The only officially recognized digital proof of age is the state-issued driver's license or eID. |
# Additional criteria like accreditation or health status for access to a venue or to take some action. | # 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. | * 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, | + | * 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 | + | * 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 locations where alcohol is available will be 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 | + | * A holder at a venue can wander around during the transaction (either physically or virtually) 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 transaction. The approach taken here is to list all of the user claims that MIGHT BE required on the access token. |
===Trigger=== | ===Trigger=== | ||
| − | The person | + | The person trying to obtain an access token that required notarization. |
==Scenarios== | ==Scenarios== | ||
| Line 32: | Line 45: | ||
# Holder is at a website that requires IAL2 identity assurance or higher for one particular transaction. | # Holder is at a website that requires IAL2 identity assurance or higher for one particular transaction. | ||
Secondary Scenario | Secondary Scenario | ||
| − | # Holder | + | # Holder is at a website that requires IAL2 identity assurance for a continuing series of transactions over time. |
==Successful Outcome== | ==Successful Outcome== | ||
| − | # The | + | # The holder is able to present a sealed access token at the entrance portal and get through to the desired resource with minimal additional hassle regardless of the level of assurance needed at each step. |
| − | # Access checks at internal points can all be enabled with the same access token used at the | + | # Access checks at internal points can all be enabled with the same access token used at the initial portal. |
| − | # Where access is denied the patron can be informed of the required attribute that was not available in the token. | + | # Where access is denied the patron can be informed of the required attribute that was not available in the token. (This can also enable attacks and so must be carefully applied.) |
==Unsuccessful Outcome== | ==Unsuccessful Outcome== | ||
| − | # | + | # Verification 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. |
| − | #Failure to access at | + | #Failure to access at the entrance portal. The reason should be clear as a ticket counter available to get adjustments as required. |
| − | # | + | #The Notary may need to be part of the process of getting a document this they are able to apply the [[Notary Seal]. |
==Privacy Concerns== | ==Privacy Concerns== | ||
* The access token may contain more information that is required for the current visit. | * 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 | + | * Presence or lack of specific attributes in the token can be determine at any access point on the site. |
| − | * The user attribute data is maintained at the | + | * The user attribute data is maintained at the acmes point for future use and is not well protected. |
| − | * User has no simple means to tell the | + | * User has no simple means to tell the accessed site to delete stored data. |
==Issues== | ==Issues== | ||
| − | # The | + | # The holder is one of the 19% of the population w/o a smart phone. Perhaps her grandchild can help with that. |
| − | # Getting the wallet into the | + | # Getting the wallet into the holder's smart phone or lap top may prove to be challenging. |
| − | # The | + | # The holder is not comfortable with technology. |
| − | # Who determines what data from the MDL is sent to | + | # The holder may initially find few notaries that capable of creating the desired seal. This is similar to the different seals that a notary might be authorized to apply in the real-world today. |
| + | # Who determines what data from the MDL is sent to web site , or the notary? (e.g., the public health details or explicit user consent)? | ||
# Is the driver's license ID number may be used for long term tracking of the user.? | # Is the driver's license ID number may be used for long term tracking of the user.? | ||
| − | # Is a picture required for | + | # Is a picture required for holder matching to the web site access points. |
# Is fraud one of the threats to be addressed within the scope of the recommendation? | # Is fraud one of the threats to be addressed within the scope of the recommendation? | ||
| + | |||
| + | ==Other Solutions== | ||
| + | * 2025-08-14 From Eve Maler | ||
| + | Never met Dentity before? It’s a decentralized identity leader with impressive proof points around scale, range, and execution. Its infrastructure has already processed millions of credentials and handles 5,000 clients such as the Ethereum Name Service (ENS), Identity Digital, AARP, and the National Notary Association, all while giving individuals more control. | ||
| + | |||
| + | I’ve been observing decentralized identity — and, in a recent past life, ideating and prototyping use cases with customers — for a long, long time. I love Dentity’s ethos and what it’s doing, and its fearless leader Jeffrey Schwartz is an absolute business legend. | ||
| + | |||
| + | In the spirit of helping the tech world develop irresistible identity strategies, I can’t wait to work with Jeffrey and team to take it to the next level. | ||
| + | |||
| + | (Why the pic of Hermoine’s beaded bag with undetectable extension charm? In our ForgeRock days, David Luna and I tried to get people to rename the wallet to “bag of holding”. And yes, I own one.) | ||
==References== | ==References== | ||
Latest revision as of 12:58, 14 August 2025
Contents
Full Title
This is a Use Case for the application of 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 the face-to-face requirement can be met by 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
- Holder seeking access to one (or more) game.
- Notary is used here to mean a notary public or other individual authorized to perform a notarial act as may be required for the acceptance of a digital document.
- Verification 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.
- 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.
- Here notary may apply to a person that is actively involved in a real-time interactive transaction with the real-world human, or it may just be an Artificial Intelligence bot interacting with the human. In some cases the AI bot may be on the user's device or in the cloud.
Taxonomy
- Notary Seal = a verifiable digital indictor that a nortorial act has successful been preformed.
- Roles
- Basic Notarization of simple the presences and the intent of the signer with a hash of the document. The name of the document might be an optional field.
- Enhanced Notarization would include some evaluation of the form and complements of the document. It is not intended the this would go so far as to verification of the contents of the document.
Contents of a digital notary seal
- hash of doc notarized
- category of notary in this instance
- date and place notarized
- id of notary + things like dates and authority (this might be a credential all on its own)
Preconditions
- A state with strict rules about (for example):
- Minors access to alcoholic beverages. The only officially recognized digital proof of age is the state-issued driver's license or eID.
- 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 locations where alcohol is available will be 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 holder at a venue can wander around during the transaction (either physically or virtually) 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 transaction. The approach taken here is to list all of the user claims that MIGHT BE required on the access token.
Trigger
The person trying to obtain an access token that required notarization.
Scenarios
Primary Scenario:
- Holder is at a website that requires IAL2 identity assurance or higher for one particular transaction.
Secondary Scenario
- Holder is at a website that requires IAL2 identity assurance for a continuing series of transactions over time.
Successful Outcome
- The holder is able to present a sealed access token at the entrance portal and get through to the desired resource with minimal additional hassle regardless of the level of assurance needed at each step.
- Access checks at internal points can all be enabled with the same access token used at the initial portal.
- Where access is denied the patron can be informed of the required attribute that was not available in the token. (This can also enable attacks and so must be carefully applied.)
Unsuccessful Outcome
- Verification 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.
- Failure to access at the entrance portal. The reason should be clear as a ticket counter available to get adjustments as required.
- The Notary may need to be part of the process of getting a document this they are able to apply the [[Notary Seal].
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 on the site.
- The user attribute data is maintained at the acmes point for future use and is not well protected.
- User has no simple means to tell the accessed site to delete stored data.
Issues
- The holder is one of the 19% of the population w/o a smart phone. Perhaps her grandchild can help with that.
- Getting the wallet into the holder's smart phone or lap top may prove to be challenging.
- The holder is not comfortable with technology.
- The holder may initially find few notaries that capable of creating the desired seal. This is similar to the different seals that a notary might be authorized to apply in the real-world today.
- Who determines what data from the MDL is sent to web site , or the notary? (e.g., the public health details or explicit user consent)?
- Is the driver's license ID number may be used for long term tracking of the user.?
- Is a picture required for holder matching to the web site access points.
- Is fraud one of the threats to be addressed within the scope of the recommendation?
Other Solutions
- 2025-08-14 From Eve Maler
Never met Dentity before? It’s a decentralized identity leader with impressive proof points around scale, range, and execution. Its infrastructure has already processed millions of credentials and handles 5,000 clients such as the Ethereum Name Service (ENS), Identity Digital, AARP, and the National Notary Association, all while giving individuals more control.
I’ve been observing decentralized identity — and, in a recent past life, ideating and prototyping use cases with customers — for a long, long time. I love Dentity’s ethos and what it’s doing, and its fearless leader Jeffrey Schwartz is an absolute business legend.
In the spirit of helping the tech world develop irresistible identity strategies, I can’t wait to work with Jeffrey and team to take it to the next level.
(Why the pic of Hermoine’s beaded bag with undetectable extension charm? In our ForgeRock days, David Luna and I tried to get people to rename the wallet to “bag of holding”. And yes, I own one.)
References
- See wiki page on Presentation from a Wallet
