# Organisation Digital Identity (ODI) use case during domain name validations
[TOC]
## Data schema descriptions
The following data schema is based on the work done for Proof of business PoC at Bolagsverket (Swedish Companies Registration Office) carried out together with Finnish and Norwegian counterparts. This is based on the nordic smart government [1] company registration data models.
| Field name | Description | Example Value |
| ----------------------------------- | ------------------------------------------- | -------------------------------------- |
| legalStatus | Legal status of the organisation | ACTIVE |
| legalForm | Legal form of the organisation | Aktiebolag |
| activity | Sector to which the organisation belongs to | Real Estate |
| orgNumber | Organisational identity | 559133-2720 |
| registrationDate | Data of registration | 2005-10-08 |
| registeredAddress.fullAddress | Full address of the organisation | Sveavägen 48, 111 34 Stockholm, Sweden |
| registeredAddress.thoroughFare | The street name | Sveavägen |
| registeredAddress.postName | The post name | Stockholm |
| registeredAddress.locatorDesignator | The street number | 111 34 |
| registeredAddress.code | Postal code | 48 |
| registeredAddress.adminUnitLevel1 | Country of registration | SE |
| attestationValidity | Validity of the attestation | 31-Dec.2022 |
## Create SD-JWT credential
The SD-JWT structure corresponding to the data schema is described in this chapter.
### Claims to be issued
```json=
{
"legalStatus": "ACTIVE",
"legalForm": "Aktiebolag",
"activity": "Real Estate",
"orgNumber": "559133-2720",
"registrationDate": "2005-10-08",
"registeredAddress": {
"fullAddress": "123 Main St",
"thoroughFare": "Sveavägen",
"postName": "Stockholm",
"locatorDesignator": "111 34",
"code": "48",
"adminUnitLevel1": "SE"
},
"attestationValidity": "31-Dec-2022"
}
```
### Formulate the payload
To create `_sd` field in the payload, following steps are carried out:
#### 1. Calculate the disclosures for each `[salt, key and value]`
```json=
[
[ "4db00f52e423ecbed02dbbd451a293d7","legalStatus","ACTIVE"],
[ "eb7483c4c0e2abbf86cbd9d44be26fa9","legalForm","Aktiebolag"],
[ "00a3792d4899c4f1c82d93b708ce5779","activity","Construction Industry"],
["b8baea64d0c71fe8064a377379b4f692","orgNumber", "559133-2720"],
["58b5e2e804ce013ea660cac84e3bc65a","registrationDate","2005-10-18"],
["1aef74d6a110104e0a2bc5e1ef4f4429","registeredAddress",{
"fullAddress": "123 Main St",
"thoroughFare": "Sveavägen",
"postName": "Stockholm",
"locatorDesignator": "111 34",
"code": "48",
"adminUnitLevel1": "SE"}],
["f95d7ca0c8e6806f84e23b0ac328a0de","attestationValidity","31-Dec-2022"]
]
```
#### 2. Apply Base64 encoding for each disclosure.
```=
[
"WyIxODY4ZTc1NjY1YzI2MzgwNGY0OTY2YjAxMmNkODRhZiIsICJsZWdhbFN0YXR1cyIsICJBQ1RJVkUiXQ",
"WyIyZDk3MjhlNmQ5NjA3ZDgxNzU0MzEyNmJkNjFkZGQ1YiIsICJsZWdhbEZvcm0iLCAiQWt0aWVib2xhZyJd",
"WyIyMWZiODg0YjM4YjJiMzM3MzU4ZThjMzAwNDcxNGY0ZCIsICJhY3Rpdml0eSIsICJDb25zdHJ1Y3Rpb24gSW5kdXN0cnkiXQ",
"WyJhMzcyMjZmZDZiOGQ2NWU5MmVlNGYyOWQwNzAzMWQ0YyIsICJvcmdOdW1iZXIiLCAiNTU5MTMzLTI3MjAiXQ",
"WyJiMDY0ODc0NzUxMWIxMmE5ZTk2MjRjMzdiYzNlZGFjYSIsICJyZWdpc3RyYXRpb25EYXRlIiwgIjIwMDUtMTAtMTgiXQ",
"WyJjMTJiMzc0ZjU4NTBlNjAwOGI4ZDA4OWZhMGU3OWE5YSIsICJyZWdpc3RlcmVkQWRkcmVzcyIsIHsiZnVsbEFkZHJlc3MiOiAiMTIzIE1haW4gU3QiLCAidGhvcm91Z2hGYXJlIjogIlN2ZWF2XHUwMGU0Z2VuIiwgInBvc3ROYW1lIjogIlN0b2NraG9sbSIsICJsb2NhdG9yRGVzaWduYXRvciI6ICIxMTEgMzQiLCAiY29kZSI6ICI0OCIsICJhZG1pblVuaXRMZXZlbDEiOiAiU0UifV0",
"WyI0ZjBjMTc4YzY3NTVjYTJkZDhmNzQ0NGE4MDNmOWY4MyIsICJhdHRlc3RhdGlvblZhbGlkaXR5IiwgIjMxLURlYy0yMDIyIl0"
]
```
#### 3. Calculate SHA-256 digest on each encoded disclosures.
```json=
[
"UJMYCqjpYiF0paMrRDxQeU2kmQllmnMPaAb4IiqA6pY",
"R3c4ca8Zo6UeNp1Ut0pHwtqtYdNwK4Mm4a-rTJY6svI",
"IbF8ND10qaWb2TgXmplCC0u3-hXOgiuXTIS3SJIcqI8",
"FCW1A9OiUpKpZlCd66B2i4M1uSaiTq4ans_853g8gas",
"3EMgx1jT9Sy5l_iogB0cGKOWzeZD5nDxTstaUPNFKd0",
"nvjcqeQU7_BkRyKYq4kv1Shr3cXh3KY4-CM2OERWpP0",
"eG1U-3lpt5R2B3Pu4nNdR03NagOPGKozV_gcN-LnkgM"
]
```
#### 4. Add decoy digests to the disclosure, if needed.
```json=
[
"NBYe--lxzk-cecoEKLToVzaurPl9EMKDEegh4Tvp49I",
"13D-K81d8E8axyHdJ7wezpzY4ZTXyF4vqAoKByMfdpc",
"1cughyxT42LVDArfKqXevh2ytU2mkc7DntDZYt9kKwg",
"uTUiyshzK3dACACr3Dtja6OwttXESaiAQ9EQS1MAWZg",
"8p-DjUMKZah-Vdfod2SHeK6EGjWa0Ww1a-LqwQGpk_w",
"3NntwLqWuRyDno1BsWxWvlvY03DgxeMbvWwxiImdtm8",
"MQAsjTkZrm1bTwCetZWtyFR1ugCFpjL1AFXWQDltNCw",
"b0TsGvfCuRVXj9Ey1wUE6SeHAYDvZ1AfwcXSIfkGumU",
"cqLjKqLRPc7Jrm3nc-d74skx1UOFZVKZCmwncO3GYlE",
"3FX-zVTKt3d1vfJbDJWMZ2HQhrCPbMPhSe3AZt7eO1Y"
]
```
#### 5. Sign the payload and create SD-JWT
For the above claim, we calculate the full disclosure of the ODI credential and the hash (using SHA-256) as given below:
Disclosure:
```!
eyJhbGciOiJFUzI1NiJ9.eyJfc2QiOlsiVUpNWUNxanBZaUYwcGFNclJEeFFlVTJrbVFsbG1uTVBhQWI0SWlxQTZwWSIsIlIzYzRjYThabzZVZU5wMVV0MHBId3RxdFlkTndLNE1tNGEtclRKWTZzdkkiLCJJYkY4TkQxMHFhV2IyVGdYbXBsQ0MwdTMtaFhPZ2l1WFRJUzNTSkljcUk4IiwiRkNXMUE5T2lVcEtwWmxDZDY2QjJpNE0xdVNhaVRxNGFuc184NTNnOGdhcyIsIjNFTWd4MWpUOVN5NWxfaW9nQjBjR0tPV3plWkQ1bkR4VHN0YVVQTkZLZDAiLCJudmpjcWVRVTdfQmtSeUtZcTRrdjFTaHIzY1hoM0tZNC1DTTJPRVJXcFAwIiwiZUcxVS0zbHB0NVIyQjNQdTRuTmRSMDNOYWdPUEdLb3pWX2djTi1MbmtnTSIsIk5CWWUtLWx4emstY2Vjb0VLTFRvVnphdXJQbDlFTUtERWVnaDRUdnA0OUkiLCIxM0QtSzgxZDhFOGF4eUhkSjd3ZXpwelk0WlRYeUY0dnFBb0tCeU1mZHBjIiwiMWN1Z2h5eFQ0MkxWREFyZktxWGV2aDJ5dFUybWtjN0RudERaWXQ5a0t3ZyIsInVUVWl5c2h6SzNkQUNBQ3IzRHRqYTZPd3R0WEVTYWlBUTlFUVMxTUFXWmciLCI4cC1EalVNS1phaC1WZGZvZDJTSGVLNkVHaldhMFd3MWEtTHF3UUdwa193IiwiM05udHdMcVd1UnlEbm8xQnNXeFd2bHZZMDNEZ3hlTWJ2V3d4aUltZHRtOCIsIk1RQXNqVGtacm0xYlR3Q2V0Wld0eUZSMXVnQ0ZwakwxQUZYV1FEbHROQ3ciLCJiMFRzR3ZmQ3VSVlhqOUV5MXdVRTZTZUhBWUR2WjFBZndjWFNJZmtHdW1VIiwiY3FMaktxTFJQYzdKcm0zbmMtZDc0c2t4MVVPRlpWS1pDbXduY08zR1lsRSIsIjNGWC16VlRLdDNkMXZmSmJESldNWjJIUWhyQ1BiTVBoU2UzQVp0N2VPMVkiXSwiX3NkX2FsZyI6InNoYS0yNTYiLCJleHAiOjE2ODczNzIwNDksImlhdCI6MTY4NzM2ODQ0OSwiaXNzIjoiaHR0cHM6Ly9pc3N1ZXIuaWdyYW50LmlvIn0.bBUsT64A9yrQPDzBX8mnGUiQ10lTKlJFWIJVHUuRySMuCUFvywohTO2WVSYepQQoV2jF9s2a7mDoaOi2b3KxpA
```
The payload for full disclosure is:
```json=
{
"_sd": [
"UJMYCqjpYiF0paMrRDxQeU2kmQllmnMPaAb4IiqA6pY",
"R3c4ca8Zo6UeNp1Ut0pHwtqtYdNwK4Mm4a-rTJY6svI",
"IbF8ND10qaWb2TgXmplCC0u3-hXOgiuXTIS3SJIcqI8",
"FCW1A9OiUpKpZlCd66B2i4M1uSaiTq4ans_853g8gas",
"3EMgx1jT9Sy5l_iogB0cGKOWzeZD5nDxTstaUPNFKd0",
"nvjcqeQU7_BkRyKYq4kv1Shr3cXh3KY4-CM2OERWpP0",
"eG1U-3lpt5R2B3Pu4nNdR03NagOPGKozV_gcN-LnkgM",
"NBYe--lxzk-cecoEKLToVzaurPl9EMKDEegh4Tvp49I",
"13D-K81d8E8axyHdJ7wezpzY4ZTXyF4vqAoKByMfdpc",
"1cughyxT42LVDArfKqXevh2ytU2mkc7DntDZYt9kKwg",
"uTUiyshzK3dACACr3Dtja6OwttXESaiAQ9EQS1MAWZg",
"8p-DjUMKZah-Vdfod2SHeK6EGjWa0Ww1a-LqwQGpk_w",
"3NntwLqWuRyDno1BsWxWvlvY03DgxeMbvWwxiImdtm8",
"MQAsjTkZrm1bTwCetZWtyFR1ugCFpjL1AFXWQDltNCw",
"b0TsGvfCuRVXj9Ey1wUE6SeHAYDvZ1AfwcXSIfkGumU",
"cqLjKqLRPc7Jrm3nc-d74skx1UOFZVKZCmwncO3GYlE",
"3FX-zVTKt3d1vfJbDJWMZ2HQhrCPbMPhSe3AZt7eO1Y"
],
"_sd_alg": "sha-256",
"exp": 1687372126,
"iat": 1687368526,
"iss": "https://issuer.igrant.io"
}
```
SD-JWT header:
```json=
{'alg': 'ES256'}
```
### Create combined format for issuance (a.k.a issue credential to holder)
For selective disclosure, each attestation is separately encoded and hashed and issued in a format given below:
`<SD-JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>`
(This is as per section 5.3 of SD-JWT spec [2]). Here, the data format for sending the SD-JWT and the Disclosures to the Holder MUST be a series of base64url-encoded values, each separated from the next by a single tilde ('~') character.
For the ODI claim we used, the SD-JWT with selective disclosure will be as given:
```!
eyJhbGciOiJFUzI1NiJ9.eyJfc2QiOlsiVUpNWUNxanBZaUYwcGFNclJEeFFlVTJrbVFsbG1uTVBhQWI0SWlxQTZwWSIsIlIzYzRjYThabzZVZU5wMVV0MHBId3RxdFlkTndLNE1tNGEtclRKWTZzdkkiLCJJYkY4TkQxMHFhV2IyVGdYbXBsQ0MwdTMtaFhPZ2l1WFRJUzNTSkljcUk4IiwiRkNXMUE5T2lVcEtwWmxDZDY2QjJpNE0xdVNhaVRxNGFuc184NTNnOGdhcyIsIjNFTWd4MWpUOVN5NWxfaW9nQjBjR0tPV3plWkQ1bkR4VHN0YVVQTkZLZDAiLCJudmpjcWVRVTdfQmtSeUtZcTRrdjFTaHIzY1hoM0tZNC1DTTJPRVJXcFAwIiwiZUcxVS0zbHB0NVIyQjNQdTRuTmRSMDNOYWdPUEdLb3pWX2djTi1MbmtnTSIsIk5CWWUtLWx4emstY2Vjb0VLTFRvVnphdXJQbDlFTUtERWVnaDRUdnA0OUkiLCIxM0QtSzgxZDhFOGF4eUhkSjd3ZXpwelk0WlRYeUY0dnFBb0tCeU1mZHBjIiwiMWN1Z2h5eFQ0MkxWREFyZktxWGV2aDJ5dFUybWtjN0RudERaWXQ5a0t3ZyIsInVUVWl5c2h6SzNkQUNBQ3IzRHRqYTZPd3R0WEVTYWlBUTlFUVMxTUFXWmciLCI4cC1EalVNS1phaC1WZGZvZDJTSGVLNkVHaldhMFd3MWEtTHF3UUdwa193IiwiM05udHdMcVd1UnlEbm8xQnNXeFd2bHZZMDNEZ3hlTWJ2V3d4aUltZHRtOCIsIk1RQXNqVGtacm0xYlR3Q2V0Wld0eUZSMXVnQ0ZwakwxQUZYV1FEbHROQ3ciLCJiMFRzR3ZmQ3VSVlhqOUV5MXdVRTZTZUhBWUR2WjFBZndjWFNJZmtHdW1VIiwiY3FMaktxTFJQYzdKcm0zbmMtZDc0c2t4MVVPRlpWS1pDbXduY08zR1lsRSIsIjNGWC16VlRLdDNkMXZmSmJESldNWjJIUWhyQ1BiTVBoU2UzQVp0N2VPMVkiXSwiX3NkX2FsZyI6InNoYS0yNTYiLCJleHAiOjE2ODczNzIxMjYsImlhdCI6MTY4NzM2ODUyNiwiaXNzIjoiaHR0cHM6Ly9pc3N1ZXIuaWdyYW50LmlvIn0.jvwxkiKTqKaGqlywgQgrwlXV91hIldSZcUsnoBvFLEpTwE75Jc9T0-s8scoOm9C9Lujm8atUt5aR1EpCfWXEBA~WyIxODY4ZTc1NjY1YzI2MzgwNGY0OTY2YjAxMmNkODRhZiIsICJsZWdhbFN0YXR1cyIsICJBQ1RJVkUiXQ~WyIyZDk3MjhlNmQ5NjA3ZDgxNzU0MzEyNmJkNjFkZGQ1YiIsICJsZWdhbEZvcm0iLCAiQWt0aWVib2xhZyJd~WyIyMWZiODg0YjM4YjJiMzM3MzU4ZThjMzAwNDcxNGY0ZCIsICJhY3Rpdml0eSIsICJDb25zdHJ1Y3Rpb24gSW5kdXN0cnkiXQ~WyJhMzcyMjZmZDZiOGQ2NWU5MmVlNGYyOWQwNzAzMWQ0YyIsICJvcmdOdW1iZXIiLCAiNTU5MTMzLTI3MjAiXQ~WyJiMDY0ODc0NzUxMWIxMmE5ZTk2MjRjMzdiYzNlZGFjYSIsICJyZWdpc3RyYXRpb25EYXRlIiwgIjIwMDUtMTAtMTgiXQ~WyJjMTJiMzc0ZjU4NTBlNjAwOGI4ZDA4OWZhMGU3OWE5YSIsICJyZWdpc3RlcmVkQWRkcmVzcyIsIHsiZnVsbEFkZHJlc3MiOiAiMTIzIE1haW4gU3QiLCAidGhvcm91Z2hGYXJlIjogIlN2ZWF2XHUwMGU0Z2VuIiwgInBvc3ROYW1lIjogIlN0b2NraG9sbSIsICJsb2NhdG9yRGVzaWduYXRvciI6ICIxMTEgMzQiLCAiY29kZSI6ICI0OCIsICJhZG1pblVuaXRMZXZlbDEiOiAiU0UifV0~WyI0ZjBjMTc4YzY3NTVjYTJkZDhmNzQ0NGE4MDNmOWY4MyIsICJhdHRlc3RhdGlvblZhbGlkaXR5IiwgIjMxLURlYy0yMDIyIl0~WyI0MjEyNDUyN2NhNjc4NTgwZWFhNzBmYTI3NTViYTRhNSIsIDAsIDBd~WyIwNjI2MTIyZGI2ODc2NDg3NTE3MzUyM2JlM2ZjNmUxMSIsIDEsIDFd~WyJjMGJjMzk1YzNkZTFiZDYyMzk4MGI5NDUyMjA5ZThiNCIsIDIsIDJd~WyJhZWU3NTg3ZmRjMDQ1NzgyY2Y3NDdhNThlMDAyOWU2ZSIsIDMsIDNd~WyI3Yzc3OTYwNDEwYTZlMDQwNTM2OWFjZjFmYzc2ODNhOCIsIDQsIDRd~WyIwZjg3NzUwZmI2MjY1NDE4OGUxOTk5ZmRjNzYyNWI2MCIsIDUsIDVd~WyI0MTJjYWVmZTU5MDYxNmYyMzVlZjUxYjg3OWY5YzIxYyIsIDYsIDZd~WyIzMzljY2RmYzJhYzRkMjUyNjU3ZmUzM2QxNTI5YTExZSIsIDcsIDdd~WyI4ZTQzZjM5YmY3MTNiODI5MmRiZTdkMTNhMDhkZTBiZCIsIDgsIDhd~WyI1YWEwZjI4ZmQ1OGJjYzFhNDQyY2Y5NzQxYTM2ZTI0NiIsIDksIDld
```
## SD-JWT Playground
The following draft implementations could be used to try out Issuer-Holder-Verifier scenarios with SD-JWT based ODIs:
Note: You need to run the SD-JWT playground locally to see it in action. Clone the repo at https://github.com/decentralised-dataexchange/sd-jwt-playground and follow the instructions provided in the [README.md](https://github.com/decentralised-dataexchange/sd-jwt-playground#instructions-to-run).
* For issuer-holder scenarios use this link - http://127.0.0.1:8888/lab/tree/notebooks/sd-jwt/issuer_holder_scenarios.ipynb
* For holder-verifier scenarios use this link - http://127.0.0.1:8888/lab/tree/notebooks/sd-jwt/holder_verifier_scenarios.ipynb
## Usecase flows
### UC-ODI-ORG-ADMIN-REQUESTS-01
| ID | UC-ODI-ORG-ADMIN-REQUESTS-01 |
| --- | --- |
| Name | Request company credentials to be issued |
| Description | The use case implements a request from an authorised Company Admin to have company credentials issued by Bolagsverket. |
| Trigger (the event that triggers the use case) | The Company Admin wishes to use their credentials in a bidding tool to prove their business. |
| Preconditions (list of conditions that MUST be met for the use case to be successful) | The Company Admin is already authenticated to the MyCompany Portal using existing mechanisms (e.g. BankID) The Company Admin has the credentials to request and perform the required operations. |
| Data inputs | The company logged-in info, Company name, Company Wallet, and Decentralised Identifier (DID) to the least. |
| Actors (a person, a company or organisation, a computer program, or a computer system - hardware, software, or both) | The Company Admin (E.g. Bygg AB) MyCompany Wallet Portal (E.g. Bolagsverket provided) Wallet instance belonging to the Company (E.g. Bygg AB) Issuer Admin Portal (E.g. Bolagsverket) |
| Normal Course (what happens if the event is triggered and the preconditions have been met) | In the MyCompany Portal, the Company Admin chooses the available company credentials. Submit the request by clicking “Request”, which is sent to the Issuer Admin Portal (Bolagsverket). |
| Alternative Course (links to other use cases in case there are different ways to solve the same use case) | NA, for now |
| Data output | None |
| Post-Conditions (the success criteria) | Company Admin gets a message “Request sent to Issuer”. A notification of the request is sent to the Issuer. |
| Exceptions (error situations) | NA, for now |
### UC-ODI-ORG-ADMIN-VIEW-01
| ID | UC-ODI-ORG-ADMIN-VIEW-01 |
| --- | --- |
| Name | View credentials issued to a company |
| Description | The use case implements an authorised Company Admin to view the company credentials issued by Bolagsverket. |
| Trigger | The company views a notification of new credentials being issued. |
| Preconditions (list of conditions that MUST be met for the use case to be successful) | The Company Admin is already authenticated to the MyCompany Portal using existing mechanisms (e.g. BankID) The Company Admin has the necessary credentials to perform the required operations. UC-BOL-ADMIN-ISSUE-01 |
| Data inputs | NA |
| Actors | The Company Admin (Bygg AB) MyCompany Portal (Bolagsverket) Wallet instance belonging to the Company (Bygg AB) |
| Normal Course (what happens if the event is triggered and the preconditions have been met) | In the MyCompany Portal, the Company Admin views the notification that new credentials have been issued. The Company Admin clicks on the notification. The MyCompany Portal shows the detailed credentials from the wallet instance belonging to the Company. Note: The above steps can be automated as well and are configurable. It's elaborated here to showcase the steps involved, primarily for demo purposes. |
| Alternative Course | NA, for now, |
| Data output | None |
| Post-Conditions (the success criteria) | The Company Admin can view the detailed company credentials issued by Bolagsverket. |
| Exceptions (error situations) | NA, for now, |
### UC-ODI-ADMIN-VIEW-01
| ID | UC-ODI-ADMIN-VIEW-01 |
| --- | --- |
| Name | View list of companies requesting credentials |
| Description | The use case implements the issuer admin to view the credential requests. Note that this can be automated as well. |
| Trigger (the event that triggers the use case) | The issuer admin at Bolagsverket (BOL) views a notification of new credential requests. |
| Preconditions (list of conditions that MUST be met for the use case to be successful) | The Issuer Admin is logged into the Issuer Admin portal. The Issuer Admin has sufficient privileges to perform administrative operations. |
| Data inputs | NA |
| Actors | The Issuer Admin (BOL) Issuer Admin Portal integrated with Issuer Controller and MyCompany admin. Wallet instance belonging to the Issuer controller |
| Normal Course (what happens if the event is triggered and the preconditions have been met) | In the Issuer Admin Portal, the Issuer Admin views the list of credentials requests. |
| Alternative Course | NA, for now |
| Data output | None |
| Post-Conditions (the success criteria) | The list of company credential issue requests is shown to the Issuer Admin (at BOL). |
| Exceptions (error situations) | NA, for now, |
### UC-ODI-DOMAIN-VALIDATION-01
| ID | UC-ODI-DOMAIN-VALIDATION-01 |
| --- | --- |
| Name | Issue credentials to the company requesting credentials |
| Description | The use case implements the Issuer Admin, via the Issuer Admin Portal to issue the requested credentials to a company. Note that this can be automated. |
| Trigger (the event that triggers the use case) | The Issuer Admin views the list of new credential requests. |
| Preconditions (list of conditions that MUST be met for the use case to be successful) | The Issuer Admin is logged into the BOL controller portal. The Issuer Admin has sufficient privileges to perform administrative operations. UC-BOL-ADMIN-VIEW-01 |
| Data inputs | NA |
| Actors | The Issuer Admin The Issuer Admin Portal integrated with BOL Controller and MyCompany controller Wallet instance belonging to the BOL controller |
| Normal Course (what happens if the event is triggered and the preconditions have been met) | For the specific request, the Issuer Admin issues the requested credentials. A success message is shown to the Issuer Admin A notification is sent to The Company via MyCompany Portal |
| Alternative Course (links to other use cases in case there are different ways to solve the same use case) | NA, for now |
| Data output | The company registration credentials (See Appendix) |
| Post-Conditions (the success criteria) | The Company is issued the requested credentials. A success message is shown to the Issuer Admin The Company Admin is notified in the MyCompany Portal of the credentials issued. |
| Exceptions (error situations) | NA, for now. |
## References
[1] Nordic Smart Government and Business: https://nordicsmartgovernment.org/
[2] IETF SD-JWT spec: https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-04.html#name-combined-format-for-issuanc
[3] SD-JWT playground: https://github.com/decentralised-dataexchange/sd-jwt-playground/blob/main/README.md
[4] jwt.io (For decoding JWT)
[5] Base64Decode: https://www.base64decode.org/
[6] Base64Encode: https://www.base64encode.org/
Sign in with Wallet
Connect another wallet