# Hotel Check-In

## Problem Statement

Hotel requests personal information from business traveler's basis Id and business information from her corporate Id. The proof request for the corporate Id has to be open ended (not restricted to a particular credential definition or issuer did) since there are many possible businesses.

Hence, we need to decide to accept a proof after getting more information about the issuer.

## Concepts

### Tagging/Classification

Allow to classify connections. Connections can be classified manually or automatically based on a defined policy.

- Issuer has to be a "verified organization"
- To be classified as "verified organization" a defined policy has to be fulfilled. In the simplest case a particualr proof request.

### External and internal policy

Proof requests/templates allow the verifier to define a policy and send it to the holder. However, in some cases it is not possible or desired to send the entire policy to the holder.

The "issued by a verified organization" restriction is such an internal policy that can't be communicated in a proof request.

#### Proof Request from hotel to employee (External Policy)

Corporate Id is only restricted to a defined schema, but not an issuer.

{
    "name": "Proof request",
    "requested_predicates": {},
    "requested_attributes": {
        "masterId": {
            "names": [
                "firstName",
                "familyName",
                "addressStreet",
                "addressZipCode",
                "addressCountry",
                "addressCity",
                "dateOfExpiry",
                "dateOfBirth"
            ],
            "non_revoked": {
                "from": 0,
                "to": 1620848663
            },
            "restrictions": [
                {
                    "cred_def_id": "XwQCiUus8QubFNJPJD2mDi:3:CL:29:masterID Dev"
                }
            ]
        },
        "corporateId": {
            "names": [
                "firmCity",
                "firmStreet",
                "firmPostalcode",
                "firmName",
                "firmSubject",
                "firstName",
                "lastName"
            ],
            "non_revoked": {
                "from": 0,
                "to": 1620848663
            },
            "restrictions": [
                {
                    "schema_id": "4cU41vWW82ArfxJxHkzXPG:2:corporateID:0.1"
                }
            ]
        }
    },
    "version": "0.1",
    "nonce": "1440979177"
}

#### Internal Policy

- Issuer has to be classified as "verified organization"

proofTemplate.requestedAttributes.restrictions.issuer === 

## Flow

The internal policy "has to be classified as verified organization" can't be evaluated directly in all cases, but should trigger a process that establishes a connection to the issuer and requests the necessary information.

@startuml
"Employee"->"Hotel": Send proof
"Hotel"->"Hotel": Verify external policy
"Hotel"->"Hotel": Verify internal policy: Unkown issuer
"Hotel"->"Hotel" ++ : Trigger process
"Hotel"->"Employer": Connection Request
"Hotel"->"Employer": Proof Request 
"Employer"->"Hotel": Proof of verified org
"Hotel"->"Hotel": Verify and classify employer
"Hotel"->"Hotel" --: Complete verification 
@enduml

This process might require additional layers. The proof request to the employer might be open ended and be answered with a proof based on an unkown issuer. Hence, we create a stack of processes and policies that need to be answered before the final decision can be made.

## Stepwise Implementation

1. Introduce the ability to tag/classify a connection
2. Introduce policies (only proof templates in the beginning?) and allow a relation to a tag, in order to auto classify a connection
- E.g. proof template asking for a organization id ("BizNum" cred) should auto-classify as "verified organization"
4. Allow to specify internal policies on top of proof templates
5. Define process rules to automaticlly collect information for policy decision