---
# System prepended metadata

title: 18.11.2021 Risk Assessment Meeting Notes
tags: [risk assessment]

---


18.11.2021 Risk Assessment Meeting Notes
===
###### tags: `risk assessment`

:::info
- **Agenda**
1. ID-Gateway Schnittstellenbeschreibung
2. SSI-Stack
3. OpenID Connect & VC
- **Participants:**
    - Martin Seiffert (AISEC)
    - Christoph Graebnitz (AISEC)
    - Silke Taligsmann (Governikus)
    - Hilke Behrens (Governikus)
    - Claus Wied (Bosch)
    - Eugeniu Rusu (Jolocom)
    - Matthias Winterstetter 
:::

## ID-Gateway Schnittstellenbeschreibung

ID Gateway Dokumentation Schnittstellenbeschreibung OpenID Connect Version 1.02


![](https://i.imgur.com/hKLDwtw.png)


**Wo finden Schritt 2 und 5 des OpenID Connect AUthentication Code Flow im vorgeschlagenen Protokollablauf statt?**
:::spoiler Authorization Code Flow (https://openid.net/specs/openid-connect-core-1_0.html)

1. Client prepares an Authentication Request containing the desired request parameters.
2. Client sends the request to the Authorization Server 
3. Authorization Server Authenticates the End-User
4. Authorization Server obtains End-User Consent/Authorization
5. Authorization Server sends the End-User back to the Client with an Authorization Code 
6. Client requests a response using the Authorization Code at the Token Endpoint.
7. Client receives a response that contains an ID Token and Access Token in the response body.
8. Client validates the ID token and retrieves the End-User's Subject Identifier.
:::
 
- Schritt 2 in Schritt 6. Es wird der Authentication Request (scope, response_type, client_id, redirect_uri, ..) als tcTokenURL übertragen (Integrated Flow = Interner Begriff Governikus)
- Schritt 5 in Schritt 13 (über Wallet als Browser)


**Wie erhält das ID-Gatewy den Authorization Request?**

- in Schritt 6

**In welchem Schritt validiert das ID-Gateway den Authorization Request?**

- nach Schritt 6

**tcTokenUrl = OpenID Connect authentication request?**

- ja, in schritt 6 tcTocenURL= Authentication Request, siehe Frage 1 

**Zu welchem Protokoll (OPenID-Connect Aurthorization Code Flow, Online Authentication gem. TR 03124-1,anderes ) gehört der Redirekt-Aufruf in Schritt 12?**

- gehört zum Prozess des eID-Service

**Schritt 16+17 sind vermutlich nicht mehr Teil des OpenID Connect Protocolls. Sollen hier tatsächlich Identitätsdaten übertragen werden oder nur die Nachricht über die erfolgreiche Authentisierung/Identifizierung?**

- OpenID Connect Authentication Code Flow endet mit Schritt 15

- Schrittte 16+17 sind Anwendungsspeziefisch, zum Bsp. redirect zum Service Provider. Wenn Daten an die Wallet übertragen werden müssen
## SSI-Stack 
Starting Point: https://hackmd.io/EzBvbwMyTyWu-LsHFlspbw

**Questions**

**Issuer** 

What standards/protocols are used for issuing credentials? 

Which software components do you use for this purpose? 

What standards/protocols are used to register an issuer? 

Which software components do you use for this purpose? 

What standard/protocols are used to verify identifiers and schemas? 

Which software components do you use for this purpose? 

**Holder** 

What standards/protocols are used to create/send a verifiable presentation of a credential. 

What standards/protocols are used to register a holder identifier? 

Where are the verifiable presentations of credentials specified, which you are planning to use? 

Which software components do you use for the purpose of creating and storing key material regarding SSI specific protocols? 

  
**Verifier** 

What standards/protocols are used for verifying credentials, identifiers and schemas? 

Which software components do you use for these purposes? 
  

**Verifiable Data Registry** 

What standards/protocols are used to store identifiers? 

What standards/protocols are used to store schemas? 

Who is defining schemas? 

Which software components do you use to maintain identifiers and schemas? 

How is the verifiable data registry organized (decentralized or centralized)? 

**Information to theese Queations**

Outline of the protocols -- https://docs.google.com/spreadsheets/d/1R0Y4ec1KVYErkcEgC3Qww7VR4CsCY2Lv2Bt-gfryEdw/edit#gid=1316375328

Cryptographic algorithms / protocols - https://hackmd.io/@once-sdi/Syq1FYQ-K

Aries Interop Profile
https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0302-aries-interop-profile

BBS+ Signatures 2020
https://w3c-ccg.github.io/ldp-bbs2020/#introduction

## OpenID Connect & VC

Offen ist jedoch wie in der Wallet gespeicherte Verified Credentials über das ID-Gateway ausgelesen bzw. dem Service Provider zur Verfügung gestellt werden sollen. Daher welche Rolle nimmt das ID-Gateway in diesem Fall, also im Kontext Verfified Credentials, ein und wie werden hier SSI-Protokolle und OpenID Connect miteinander verbunden um zum einen Interoperabilität (eine einheitliche Schnittstelle für den Service Provider) und Privacy-by-Design-Anforderungen im Kontext SSI zu gewährleisten.

- Current idea from Governikus: ID Gateway takes on the role of verifier if necessary and speaks OpenID Connect or a variant of it with the service provider.
- An interesting related resource - https://openid.net/wordpress-content/uploads/2021/09/OIDF_OIDC4SSI-Update_Kristina-Yasuda-Torsten-Lodderstedt.pdf