An **Action** is something that is actually done/executed by a %%actor|actor%% in some context (i.e. in a specific place, at a specific time). During the time interval in which the action is executed, the actor may still execute other actions in other execution-contexts (multi-tasking). An action is executed for, or on behalf of, a specific %%party|party%%, which means that the primary guidance for executing the action, e.g. how to execute it, boundary conditions within which the execution must take place, etc., comes from a %%policy|policy%% that this %%party|party%% has established for actions of that kind. The actor is assumed to have appropriate access to that policy.
An **Action** is something that is actually done/executed by a %%actor|actor%% in some context (i.e. in a specific place, at a specific time). During the time interval in which the action is executed, the actor may still execute other actions in other execution-contexts (multi-tasking). An action is executed on behalf of a specific %%party|party%%, which means that the primary guidance for executing the action, e.g. how to execute it, boundary conditions within which the execution must take place, etc., comes from a %%policy|policy%% that this %%party|party%% has established for actions of that kind. The actor is assumed to have appropriate access to that policy.
The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
### Purpose
The ability to distinguish between (non)actions allows one to determine which (kinds of) %%actors|actor%% are capable of executing actions (e.g. by establishing that they have the competences required by the %%party|party%%), and as a consequence may be permitted and/or required to execute them. Also, this ability enables %%parties|party%% to determine the execution-policy, i.e. the set of rules, working-instructions, preferences and other guidance that actors should obey or comply with when exeucting an action on its behalf.
...
...
@@ -27,5 +29,3 @@ An **Action** is something that is done by an actor, can be considered a single
- %%actor|actor%%
- %%agent|agent%%
### Background
The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
@@ -11,6 +11,8 @@ hoverText: "Actor: Entity that can act (do things), e.g. people, machines, but n
### Short Description
An **Actor** is someone or something that can actually do things, such as people or machines. Actors will generally do things, i.e. execute %%actions|action%% in different ways, depending on the context, or the %%party|party%% for whom they do this.
The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
### Purpose
The ability to distinguish between (non)actors allows one to determine which (kinds of) actors are capable of executing which (kinds of) %%actions|action%%, specifically since %%organizations|organization%% do not qualify as an actor (they need actors to get things done).
...
...
@@ -29,6 +31,3 @@ Entity that is capable of actually executing %%actions|action%% (acting, doing t
- %%peer actor|peer-actor%%
- %%agent|agent%%
- %%principal|principal%%
### Background
The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
An **Agent** is an %%actor|actor%% that is executing an action %%action|action%% for, or on behalf of some %%party|party%% (which we call the %%principal|principal%% of that agent). During the time interval in which the action is executed, the actor may execute other actions in other execution-contexts, on behalf of the same or another %%party|party%%. However, for the execution of a single %%action|action%%, the actor is an agent for precisely one principal. It is assumed that the principal provides its agents with the %%policies|policy%% that provide the agents with the rules, working-instructions, preferences and other guidance that they need to comply with when exeucting the action.
An **Agent** is an %%actor|actor%% that is executing an action %%action|action%% on behalf of some %%party|party%% (which we call the %%principal|principal%% of that agent). During the time interval in which the action is executed, the actor may execute other actions in other execution-contexts, on behalf of the same or another %%party|party%%. However, for the execution of a single %%action|action%%, the actor is an agent for precisely one principal. It is assumed that the principal provides its agents with the %%policies|policy%% that provide the agents with the rules, working-instructions, preferences and other guidance that they need to comply with when exeucting the action.
The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
### Purpose
The ability to distinguish between (non)agents is relevant in many situations, including:
- electronic communication: the agent
### Criterion
An **Agent** is a role that an %%actor|actor%% fulfills with respect to some %%party|party%% when that actor is executing some %%action|action%% for, or on behalf of that %%party|party%%.
An **Agent** is a role that an %%actor|actor%% fulfills with respect to some %%party|party%% when that actor is executing some %%action|action%% on behalf of that %%party|party%%.
### Examples
...
...
@@ -27,6 +29,3 @@ An **Agent** is a role that an %%actor|actor%% fulfills with respect to some %%p
- A company that makes cars may use robots that weld parts of a car together; these robots acts as Agents for that company.
- A (running) webserver that accepts product orders for a retailer acts as a (digital) Agent for that retailer.
- A wallet app that runs on a phone and that is exclusively used by a single person acts as a (digital) Agent for that person.
### Background
The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
TNO (or others) to provide the content of this file.
:::
### Purpose
The ability to distinguish between (non) colleagues allows us to reason and communicate about the set of (digital and non-digital) %%actors|actor%% that are %%agents|agent%% for a **principal|principal%%. This is relevant in situations where different %%agents|agent%% excute %%actions|action%% in a single %%business transaction|business-transaction%% on behalf of the same %%principal|principal%%
See also: %%digital colleague|digital-colleague%%.
@@ -12,6 +12,8 @@ hoverText: "Concept: the ideas/thoughts behind a classification of Entities (wha
<!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
A Concept tries to capture the idea behind a classification of entities[^1], allowing us to reason about everything in the class as if it were one thing. For example, the ideas ([mental representations](https://en.wikipedia.org/wiki/Mental_representation)) you have when processing the sentences "I can drink beer from a beer glass' and 'I can drink beer from a coffee mug' shows that the concepts that are behind 'beer glass' and 'coffee mug' differ. Note that in order to communicate about this idea, we also need a word or phrase (i.e.: a termat we can use to refer to (instances of) this idea.
The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
### Purpose
<!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this conceptevant within its scope of definition?-->
Working together is easier when you and your peers share the same ideas. We need a way to test and ensure, that you and your peers _actually_ have the same understanding, for the purpose of making cooperation easier. Doing so is expected to not only reduce the number of terminological discussions, but also improve the efficiency and effectiveness of the remaining discussions.
...
...
@@ -31,9 +33,6 @@ A (description/specification of a) Concept MUST be [intensionally defined](https
* %%Mental(or Conceptual) Model|pattern%% is a collection of concepts, relations between such concepts, and constraint rules that (elements of) such concepts and relations must satisfy. Such [models](https://en.wikipedia.org/wiki/Conceptual_model) are used to help people know, understand, or simulate a subject the model represents.
### Background
The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
### Domains
<!--In which general knowledge ecosystems or mental model families does this concepty a role?-->
A **credential-type** is a specification that states which kinds of %%assertions (claims, statements)|assertion%% can or may be found in any %%credential|credential%% of that kind. Typically, %%parties|party%% that issue %%credentials|credential%% of some %%kind|credential-type%% will advertise the %%credential types|credential-type%% of the %%credentials|credential%% that it may issue.
A **credential-type** is a specification that states
- the contents that %credentials of that kind must or may have; this includes of which kinds of %%assertions (claims, statements)|assertion%% as well as meta-data.
- properties Typically, %%parties|party%% that issue %%credentials|credential%% of some %%kind|credential-type%% will advertise the %%credential types|credential-type%% of the %%credentials|credential%% that it may issue.
### Purpose
%%Parties|party%% advertise %%credential types|credential-type%% for credentials that they issue for the purpose of enabling other %%parties|party%% to determine whether or not they should be asking for such %%credentials|credential%% of this issuing %party.
@@ -9,7 +9,7 @@ hoverText: "Credential: data, representing a set of Assertions (claims, statemen
---
### Short Description
A **credential** is a set of (related) %%assertions|assertion%% (also referred to as claims, or statements), to which metadata is added (e.g. date of issuing), and a number of proofs, which typically include a proof of provenance (i.e. proof that it was created by, or on behalf of, a specific %%party|party%%), and a proof of integrity (i.e. proof that the data hasn't changed since it was issued).
A **credential** is a set of (related) %%assertions|assertion%% (also referred to as claims, or statements), to which metadata is added (e.g. date of issuing), and a number of proofs, which typically include a proof of provenance (i.e. proof that it was created on behalf of a specific %%party|party%%), and a proof of integrity (i.e. proof that the data hasn't changed since it was issued).
In physical credentials, such as drivers licenses and passports, proofs of integrity usually apply to the physical document itself. They come in a variety of forms, such as the structure of the paper, holograms, watermarks, or (embedded) chips. The proof of provenance usually consists of the form-format of the credential and %%assertions|assertion%% about the document issuer.
@@ -19,7 +19,7 @@ The Data Discloser uses a %%data-collector-policy|data-collector-policy%% to lea
The Data Discloser uses the %%eSSIF-Glue|essif-glue%% interface to access the %%Wallet|wallet%%, %%Holder|holder%%, %%Issuer|issuer%% and %%Verifier|verifier%% functionalities.
### Purpose
The purpose of the Data Discloser component is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other Parties. A special kind of result is the (provisioning of) a credential that its Owner already has created.
The purpose of the Data Discloser component is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other Parties. A special kind of result is the (provisioning of) a credential that its Principal already has created.
### Criteria
A **Data Discloser** is a component in the [eSSIF-Lab functional architecture](../functional-architecture) that is capable of stating (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other %%Parties|party%%.
<!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
A **Definition** is a text that helps %%parties|party%% truly understand the meaning of a %%term|term%% as it is used in a communication. Because [terms are scoped](terminology), this 'truly understanding' of one another isn't trivial. Therefore, we insist that the explanatory text be a criterion that %%parties|party%% are expected to use in the same way in some %%scope(s)|scope%%, allowing them to establish whether or not they make the same determination as to whether or not something qualifies to be refered to by that term in a way that is independent of whether or not the (alledged) meaning is relevant for the purposes they pursue within that scope.
The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
### Purpose
<!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this conceptevant within its scope of definition?-->
Working together is easier when you and your peers share the same ideas. We need a way to test and ensure, that you and your peers _actually_ have the same understanding, for the purpose of making cooperation easier. Doing so is expected to not only reduce the number of terminological discussions, but also improve the efficiency and effectiveness of the remaining discussions.
...
...
@@ -37,9 +39,6 @@ Entity that comprises at a minimum:
* %%Mental(or Conceptual) Model|pattern%% is a collection of concepts, relations between such concepts, and constraint rules that (elements of) such concepts and relations must satisfy. Such [models](https://en.wikipedia.org/wiki/Conceptual_model) are used to help people know, understand, or simulate a subject the model represents.
### Background
The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
### Use-cases
<!--This (optional) section specifies an (optional) introductory paragraph, and a level-3 (i.e. `###`) subsection for every use case it describes. Every such use-case SHOULD
@@ -12,6 +12,8 @@ hoverText: "Dictionary: an alphabetically sorted list of Terms with various mean
<!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
A Dictionary is an alphabetically sorted list of terms and explanations. Each term may have multiple such explanations, which come from different %%scopes/contexts|scope%%.
The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
### Purpose
<!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this conceptevant within its scope of definition?-->
A dictionary helps people to get introduced in the domain for which the dictionary is created. Usually, this is a larger domain e.g. of some language, or about computer security.
...
...
@@ -29,9 +31,6 @@ Examples include the [NIST Computer Security Resource Center](https://csrc.nist.
- %%Glossary|glossary%% - this is a list of words with a single meaning, that serves more specific purposes than a dictionary.
-[Vocabulary](https://en.wikipedia.org/wiki/Vocabulary) - this is a set of familiar words witin a particular/persons's language or field of expertise. A Dictionary can provide the various meanings of each such words.
### Background
The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
### Notes
<!--This (optional) section is the place to put anything for which there is no other good place to put it.-->
@@ -11,6 +11,8 @@ hoverText: "Entity: something that is known to exist."
### Short Description
Whenever you know that somethings exists, be it another person, yourself, some computer, an extinct animal, a thought, an idea, a JSON-object, ..., _anything_ you can think of, is what the term **Entity** refers to.
The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
### Purpose
This term enables us to refer to anything, or to postulate the existence of something, without further specifying what it is, or how it might be named.
...
...
@@ -19,6 +21,3 @@ Something, anything, that some %%party|party%% knows to exist
### Related Concepts
- a %%legal entity|legal-entity%% is an entity that is known by (i.e. registered in the %%knowledge|knowledge%% of) a %%party|party%% that operates the %%legal system|legal-system%% of a %%jurisdiction|jurisdiction%%. (Details are in the %%Jurisdictions pattern|pattern-jurisdiction%%)
### Background
The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
@@ -9,39 +9,22 @@ hoverText: "Glossary: an alphabetically sorted list of Terms with the (single) m
---
### Short Description
<!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
A **glossary** is an alphabetically sorted list of %%terms|term%% with explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in (at least) one context. A glossary may also be created for the purpose of being included in other glossaries (as a construction aid to such glossaries), or for still other purposes.
The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
### Purpose
<!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this conceptevant within its scope of definition?-->
A glossary may serve various purposes, the most important one of which would be to help people understand texts around a certain (set of) topic(s) in some context(s).
### Criteria
<!--REQUIRED--How is this concept different from related ideas? What are essential characteristics that must be true? This is where you specify the [intensional definition](https://en.wikipedia.org/wiki/Extensional_and_intensional_definitions) of the concept, i.e. the necessary and sufficient conditions for when the term should be used. This makes that the conceptomes crystal clear. In the case of nouns, this is equivalent to specifying the properties that an object needs to have in order to be counted as a referent of the term.-->
A **glossary** is an alphabetical list of words or phrases with (short) explanations, that exists for the purpose of helping people to get a first understanding of the meaning of each word in the scope/context for which the glossary is created.
### Examples
<!--This (optional) section contains examples, both of what satisfies the definition (and hence qualifies as an instance of Glossary), ans what does not. If you can think of examples for which the criterion may not (always) work, then describe them, too, and inform the reader why this hasn't affected the definition (yet) - e.g. because such cases are irrelevant to the scope within which the term is defined.-->
Examples include the [eSSIF-Lab Glossary](../essifLab-glossary), the [Sovrin Glossary](https://sovrin.org/library/glossary/), the [Glossary of Internet Terms](https://www.internetsociety.org/internet/glossary-internet-terms/), and glossaries for Legal Terms, e.g. of the [US](https://www.uscourts.gov/glossary), [Singapore](https://www.supremecourt.gov.sg/services/self-help-services/glossary-of-terms), the [UK](https://www.copfs.gov.uk/involved-in-a-case/glossary-of-legal-terms).
### Related Concepts
<!--This (optional) section lists words/phrases that are encountered in other contexts that have the same or a sufficiently similar meaning as Glossary. In this section you may point out the (subtle) differences between Glossary and this related terminology. This helps readers better/deeper understand Glossary, and how it may be used to relate to existing texts. Ideally, such references are accompanied with links to (preferredly authoritative) sources.-->
- %%Dictionary|dictionary%% - this is more extensive; it usually includes multiple meanings of words, and may include additional information e.g. on pronunciation, etymology, usage, example sentences,synonyms, etc. See [askdifference.com](https://www.askdifference.com/dictionary-vs-glossary/)
-[Vocabulary](https://en.wikipedia.org/wiki/Vocabulary) - this is a set of familiar words witin a particular/persons's language or field of expertise. A Dictionary can provide the various meanings of each such words.
### Background
The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
### Notes
<!--This (optional) section is the place to put anything for which there is no other good place to put it.-->
The [eSSIF-Lab Glossary](../essifLab-glossary) contains the words that are defined within the scope of the [eSSIF-Lab framework](../project).
\ No newline at end of file
<!--
---
### Footnotes
[//]:# This (optional) section contains any footnotes that may have been specified in the text above.
@@ -15,14 +15,13 @@ As %%parties|party%% interact with one another, i.e. conduct %%business transact
Within eSSIF-Lab, governance is pretty much limited to the governance of various %%policies|policy%%.
The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
### Purpose
The purpose for a %%party|party%% of having a **governance** process is that it enables him to reflect on the ways that it makes decisions. A typical topic for governance is the maintenance of the set of rules, working-instructions, preferences and other guidance that %%actors|actor%% are supposed, or required to use when executing specific %%actions|action%% on behalf of that %%party|party%%.
For %%digital-actors|digital-actor%% such guidance consists of %%digital policies|digital-policy%%. A %%party|party%% whose governance process maintains a %%policy|policy%% will be called the %%governor|policy-governor%% of that policy.
### Background
The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
@@ -13,11 +13,10 @@ A **Guardianship-type** is a class of %%guardianship relationships|guardianship%
A good way to think abouat a %%guardianship-type|guardianship-type%% is to see it as a template from which instances - i.e. actual %%guardianship relationships|guardianship%% can be derived.
The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
### Purpose
A **Guardianship-type** serves as a template from which instances - i.e. actual %%guardianship relationships|guardianship%% can be derived. It allows the %%jurisdiction|jurisdiction%% within which it is defined to specify generic %%duties and rights|pattern-duties-and-rights%%, both for the %%guardian|guardian%% and the %%dependent|dependent%% in (instantiated) %%guardianship relationships|guardianship%%, without knowing which %%entities|entity%% will be(come) the %%guardian|guardian%% or the %%dependent|dependent%%.
### Criteria
An **guardianship-type** is a class of %%guardianship-relationships|guardianship%% that comprises a (non-empty) set of %%duty/right types|pattern-duties-and-rights%% for at least the %%guardian|guardian%% and/or the %%dependent|dependent%% (and perhaps other roles), the semantics of which are defined by the %%jurisdiction|jurisdiction%%.
### Background
The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
@@ -19,6 +19,8 @@ in which one of these %%entities|entity%% (called the %%owner|owner%%) is entitl
We may use the phrase %%natural guardianship%% to refer to an guardianship relation that exists in the %%jurisdiction|jurisdiction%% 'Nature' (see the notes of %%jurisdiction|jurisdiction%%). This enables us to talk about things as 'the (natural) guardianship of an %%assertion|assertion%%'.
The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
### Purpose
**Guardianship** is a means by which %%jurisdictions|jurisdiction%% provide assurances to %%parties|party%% (within its scope) that they can enjoy, dispose of and control in pretty much any way they like. The %%legal system|legal-system%% of the %%jurisdiction|jurisdiction%% specifies these rights, and provides ways in which the %%owner|owner%% can exercize them (that provides the assurance).
...
...
@@ -31,6 +33,3 @@ An **guardianship** is a relationship between two %%legal entities|legal-entity%
### Notes
- Owning something does not imply posessing it (and vice versa). For example, if you find a coin that doesn't belong to you, you possess it but do not own it. Also, its rightful owner obviously owns it, but doesn't possess it at that point in time.
\ No newline at end of file
### Background
The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
@@ -9,7 +9,7 @@ hoverText: "Holder (functional component): the capability to handle presentation
---
### Short Description
A **Holder** is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that handles %%Presentation Requests|presentation-request%% that it receives from %%verifier|verifier%% components (of other %%parties|party%%, but also of its own %%owner|owner%%). Typically, this means looking for the requested data in the Owner’s %%wallet|wallet%%, and using it to construct a Presentation (=response). However, if the Wallet doesn’t have it, the Holder may negotiate a transaction with a component of the designated %%issuer|issuer%% for the purpose of obtaining the needed credential, which - when obtained - it can subsequently store in the wallet and use in the Presentation.
A **Holder** is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that handles %%Presentation Requests|presentation-request%% that it receives from %%verifier|verifier%% components (of other %%parties|party%%, but also of its own %%owner|owner%%). Typically, this means looking for the requested data in the Principal’s %%wallet|wallet%%, and using it to construct a Presentation (=response). However, if the Wallet doesn’t have it, the Holder may negotiate a transaction with a component of the designated %%issuer|issuer%% for the purpose of obtaining the needed credential, which - when obtained - it can subsequently store in the wallet and use in the Presentation.
:::info Editor's note
TNO (or others) to provide additional content of this file.
...
...
@@ -25,11 +25,11 @@ A **Holder** is a component in the [eSSIF-Lab functional architecture](../functi
Typically, a Holder component would access its %%owner|owner%%'s Wallet to check if it has a credential that it can use to construct a Presentation (i.e. response) that satisfies the received request.
It may happen that the Wallet does not have such a credential. However, for every (credential, issuer) pair, the request should specify the URI that is capable of issuing such a credential. If or when the Holder Policy/Preferences permit this, the Holder then requests its Owner’s Transaction Data Collector to initiate a new transaction that will get the credential from that issuer, for which a clean transaction form would then consist of one that contains said credential. The Holder would then store it in its Owner’s Wallet, and then proceed to service the presentation request as if it had obtained that credential from its Owner’s Wallet.
It may happen that the Wallet does not have such a credential. However, for every (credential, issuer) pair, the request should specify the URI that is capable of issuing such a credential. If or when the Holder Policy/Preferences permit this, the Holder then requests its Principal’s Transaction Data Collector to initiate a new transaction that will get the credential from that issuer, for which a clean transaction form would then consist of one that contains said credential. The Holder would then store it in its Principal’s Wallet, and then proceed to service the presentation request as if it had obtained that credential from its Principal’s Wallet.
It may also happen that the Wallet has multiple credentials that satisfy the request, in which case the Holder must choose the one to use for constructing the presentation. Again, the Holder Policy/Preferences will specify how this choice needs to be made, and whether or not this can be done automatically by the Holder. If not, the Holder will need to provide for an interaction with a human Colleague that will make such decisions.
In order to make the Holder component work, a Holder Policy/Preferences object is created by, or on behalf of the Owner, which specifies e.g.:
In order to make the Holder component work, a Holder Policy/Preferences object is created by, or on behalf of its Principal, which specifies e.g.:
- whether or not credentials may be collected ‘on the fly’;
- how to choose between credentials that all satisfy a presentation request (and whether the Holder can make such choices by itself, or whether or not human interaction is required);
@@ -29,7 +29,7 @@ The purpose of the Issuer component is to issue ‘credentials’, i.e. digital
- metadata (e.g. type of credential, date of issuing and expiration, endpoints, e.g. for revocation checking, credential definition, credential advertisements, credential enforcement policy, etc.)
- proofs (e.g. a digital signature by which third %%parties|party%% can prove its provenance and integrity.
Another purpose that an Issuer might serve is to provide a means that allows any other Agent that somehow has obtained a copy or presentation of a credential, to verify whether or not the data therein is conformant to the business administration of its Owner. We will use the term ‘revocation service’ to refer to such means. Whether or not an Issuer provides such a service, and what kind of revocation service is provided (e.g. a revocation list, an online revocation status protocol, etc.), is a decision that its Owner should make, and specify in the Issuer Policies/Preferences.
Another purpose that an Issuer might serve is to provide a means that allows any other Agent that somehow has obtained a copy or presentation of a credential, to verify whether or not the data therein is conformant to the business administration of its Principal. We will use the term ‘revocation service’ to refer to such means. Whether or not an Issuer provides such a service, and what kind of revocation service is provided (e.g. a revocation list, an online revocation status protocol, etc.), is a decision that its Principal should make, and specify in the Issuer Policies/Preferences.
An Issuer component may issue credentials in various formats, e.g. as a Verifiable Credential (VC), an Attribute-Based Credential (ABC), an OpenID Connect/JWT token, etc. The issuing %%party|party%% must specify credential-types in such a way that if the same credential is issued in different formats, it is possible for an arbitrary %%verifier|verifier%% to determine whether or not two credentials that have different formats, are in fact the same. One way of doing this is that the Issuer generates an identifier for every credential that it constructs (before expressing it in a specific format).
<!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
A **Jurisdiction** is the composition of one %%scope|scope%%, one %%legal system|legal-system%% and one %%party|party%% (called the %%Governor of the Jurisdiction|jurisdiction-governor%%) that operates the legal system within that scope. While most people are familiar with what we call %%legal jurisdictions|legal-jurisdiction%%, please observe that %%organizations|organization%% habitually will have rules (business policies) in place, enforce them (to some extent), and have ways of resolving conflicts, and therefore qualify as a jurisdiction. Specifically, multi-national organizations are known to govern multiple jurisdictions, aliging the scopes with the scopes of other (often legal) jurisdictions for the purpose of preventing situations in which conflicting rules apply, which would lead to many effort-intensive conflict-resolution cases.
A **Jurisdiction** is the composition of a (non-empty) set of %%objectives|objective%%, one %%scope|scope%%, one %%legal system|legal-system%% and one %%party|party%% (called the %%Governor of the Jurisdiction|jurisdiction-governor%%) that operates the legal system within that scope. While most people are familiar with what we call %%legal jurisdictions|legal-jurisdiction%%, please observe that %%organizations|organization%% habitually will have rules (business policies) in place, enforce them (to some extent), and have ways of resolving conflicts, and therefore qualify as a jurisdiction. Specifically, multi-national organizations are known to govern multiple jurisdictions, aliging the scopes with the scopes of other (often legal) jurisdictions for the purpose of preventing situations in which conflicting rules apply, which would lead to many effort-intensive conflict-resolution cases.
The %%Jurisdictions pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
