2024 IEEE International Conference on Decentralized Applications and Infrastructures (DAPPS)

A Middleware Architecture for Self-Sovereign

2024 IEEE International Conference on Decentralized Applications and Infrastructures (DAPPS) | 979-8-3503-6295-4/24/$31.00 ©2024 IEEE | DOI: 10.1109/DAPPS61106.2024.00019

Identity Authentication and Authorization

Felix Hoops Florian Matthes
Department of Computer Science Department of Computer Science
Technical University of Munich Technical University of Munich
Munich, Germany Munich, Germany
[email protected] [email protected]

Abstract—In the evolving digital identity landscape, the con- existing services authenticate and authorize users. Simultane-
cept of Self-Sovereign Identity (SSI) has emerged as a paradigm ously, the complexity barrier for building new services is also
shift, empowering individuals with the ownership and control of rising when building for SSI compared to traditional identity
their personal information. This paper introduces a middleware
architecture that leverages the principles of SSI, enabling applica- management systems.
tion clients to authenticate and authorize users holding Verifiable As a first step, we provide an overview of existing work
Credentials via the OpenID Connect protocol. This architecture on SSI middleware for service providers, also known as
simplifies adoption for new and existing service providers by relying parties (RPs). We then contribute a new middleware
letting them build on established standards with proven tools. architecture that enables application clients to authenticate
To further simplify configuration, we introduce a tailored login
policy language based on JSON. We validate our architecture by and authorize users who hold VCs via the OpenID Connect
implementing it and testing it with different services. (OIDC) [2] protocol. In contrast to existing work, our contri-
Index Terms—Self-Sovereign Identity, Identity and Access bution is lean and fully configurable by just one single policy,
Management, Verifiable Credentials, OpenID Connect, OAuth and we also present a detailed reference of this integration on
a protocol level. To evaluate our design, we implemented it
I. I NTRODUCTION and published it as open-source software1 . We also describe
the initial testing done to validate our implementation.
The Internet, as we know it today, is dominated by a few
large identity providers (IdPs) that offer single-sign-on (SSO) II. BACKGROUND
services. These IdPs have become the gatekeepers of user In this section, we provide an overview of the concept
identities, controlling access to numerous online services and of Self-Sovereign Identity, introduce OpenID Connect with
applications. This centralized approach to identity manage- an emphasis on the core standard, and finally explore the
ment presents several challenges, including privacy concerns, newest additions to OpenID Connect that go beyond the
lack of control over personal data, and the risk of effectively core specification to provide some support for Self-Sovereign
being a single point of failure for large parts of the Internet. Identity.
In response to these challenges, the concept of Self-
Sovereign Identity (SSI) [1] has emerged. SSI is a paradigm A. Self-Sovereign Identity
shift in identity management that empowers individuals to SSI is a decentralized identity management paradigm that
own and control their digital identities. Instead of relying on aims to return a higher degree of privacy and control to
centralized identity providers, users can create, manage, and individual end-users [1] by letting them hold their own user
use their digital identities independently, enhancing privacy data. As of writing, SSI has gained momentum in research and
and security. Actors in SSI are identified by cryptographic policy communities, but large-scale adoption is yet to come.
key material, and a user’s attributes are attested to and signed Key to the technical implementation of SSI are the W3C
by IdPs, now also known as issuers, in the form of Verifiable Verifiable Credential (VC) [3] and W3C Decentralized Iden-
Credentials (VCs). tifier (DID) [4] standards. The VC standard defines a format
A drastic change in identity management paradigm poses for expressing claims, enabling the creation of digitally signed
significant challenges to IdPs and service providers. The latter statements about subjects such as individuals, organizations, or
group is considerably larger. For instance, a limited number of machines. These credentials can be cryptographically verified.
universities issue diplomas. At the same time, comparatively, Complementing VCs, the W3C DID standard establishes a
many third parties, such as corporate HR departments, rely on pattern for creating and managing globally unique decen-
these diplomas as just one part of their business processes. tralized identifiers that represent the subjects and issuers of
While identity management is the core business of an IdP, VCs. The actual implementation is up to each specific DID
service providers have limited resources to devote to that. Yet,
transitioning to SSI requires substantial changes in how these 1 https://github.com/GAIA-X4PLC-AAD/ssi-to-oidc-bridge

979-8-3503-6295-4/24/$31.00 ©2024 IEEE 79

DOI 10.1109/DAPPS61106.2024.00019
Authorized licensed use limited to: BRAC UNIVERSITY. Downloaded on April 08,2025 at 19:38:05 UTC from IEEE Xplore. Restrictions apply.
method, allowing for great flexibility. Usually, these work specifications of that family. They can be combined to create
by leveraging asymmetric encryption keys, similar to how a standardized way for smartphone wallets to authenticate and
blockchain accounts work. authorize a user with claims from VCs.
For end-users, the entry into any SSI ecosystem likely III. R ELATED W ORK
begins with a smartphone wallet application. SSI wallets are
comparable to crypto wallets in that they store private key With the field of Self-Sovereign Identity (SSI) having
material. However, their keys represent DIDs. In addition, SSI enjoyed steady attention from researchers in the past years,
wallets also provide means to store VCs, display VCs, and several authors have contributed work related to the topic of
implement protocols to present and receive VCs. integrating SSI into established identity and access manage-
Presenting a VC happens in the form of a Verifiable Presen- ment (IAM) systems. These contributions roughly fit into three
tation (VP) that contains at least one VC and a challenge and categories. We start by mentioning surveys about integrations
is signed by the holder to prevent replay attacks. A relying of SSI into existing IAMs, then go over noteworthy integra-
party (RP) can cryptographically verify the VP and its VC(s) tions with OIDC, and finally, integrations with other IAMs.
without interacting with the issuer. If designated in a VC, the A survey by Kuperberg et al. [9] looking at SSI integrations
issuer will also query a status list to ensure the VC is not for established IAM protocols identifies only seven relevant
revoked. candidates. Most are commercial, and only two are available
as open-source software. They note a need for code examples
B. OpenID Connect and an explanation of implementation specifics.
OpenID Connect (OIDC) [2] is an open standard designed In another survey, Grüner et al. [10] formalize and compare
for secure user authentication and authorization. It is built on different interoperability concepts for SSI. They are unable to
top of the OAuth 2.0 [5] authorization framework, providing clearly identify a superior concept. Also focused on interoper-
an additional layer of identity verification. OIDC facilitates the ability, Yildiz et al. [11] once more emphasize the need for true
exchange of user information between the identity provider interoperability in SSI and describe it as a key requirement for
(IdP) and the relying party (RP) in a secure and standardized further adoption. They introduce an SSI reference model that
manner. The OIDC protocol introduces a set of standardized structures SSI components and functionalities into different
identity flows adapted from OAuth 2.0, such as the Autho- layers. They also point out where specific protocols and
rization Code Flow, Implicit Flow, and Hybrid Flow, allowing standards could be applied on these layers, including OIDC
clients operated by an RP to request and obtain identity technology standards.
information about users. To limit what information a client A general survey of the state of SSI from 2022 by
gets, OpenID Connect defines a set of scopes that determine Schardong et al. [12] notes that protocol integration into
the user attributes transmitted to the client during the sign- established IAMs is vital to pave the adoption for SSI. The
in process. Ultimately, the client ends up receiving tokens. An authors provide a comprehensive list of existing efforts.
Grüner et al. introduced a system facilitating IAM between
id_token is used for identity data, such as an email address.
the old SSI ecosystems of Jolocom and uPort, as well as
An access_token encodes information relevant to access
the still-existent Hyperledger Aries, and the established IAMs
control, such as membership in a user group.
OIDC and SAML2 over the course of two works [13], [14].
One of the strengths of OpenID Connect is its ability to
The presented system works as a two-way integration and
support single sign-on (SSO) scenarios, enabling users to log
consequently assumes the role of issuer and relying party
in once and access multiple services without the need for
simultaneously. An elaborate trust model, combined with
separate authentications.
attribute mapping support, enables forwarding claims under
C. OpenID for Verifiable Credentials unified names while marking untrusted claims by renaming
Recently, OpenID Connect has been expanded by OpenID them further. The most significant issue with this architecture
for Verifiable Credentials (OID4VC) [6]. Originally, OID4VC lies in its complexity and the considerable work needed to
was a family of three specifications: integrate new blockchain-based SSI ecosystems.
Lux et al. [15] propose an integration architecture that
OpenID for Verifiable Credential Issuance (OID4VCI) allows OIDC sign-in via SSI based on a blockchain public
defines an API for VC issuance from a server to a wallet. key infrastructure. Namely, they are looking at Sovrin, which
It essentially covers the download of a signed credential. uses Hyperledger Indy. In their implementation, they write
OpenID for Verifiable Presentations (OID4VP) specifies attributes to the OIDC id_token to avoid reliance on non-
how a wallet can present a VP to a server based on an default OIDC features. Unfortunately, the solution is exclusive
OAuth 2.0 flow [7]. to Hyperledger Indy.
Self-Issued OpenID Provider v2 (SIOPv2) enables SSI At least two open-source solutions without academic contri-
wallets to act as OIDC Providers [8]. bution exist. The first one is the Province of British Columbia’s
Since then, more have been added2 , but considering our Verifiable Credential Authentication with OpenID Connect
focus on sign-ins, OID4VP and SIOPv2 are the relevant (VC-AuthN OIDC)3 . It supports a cross-device flow where the
2 https://openid.net/sg/openid4vc/specifications/ 3 https://github.com/bcgov/vc-authn-oidc

80

Authorized licensed use limited to: BRAC UNIVERSITY. Downloaded on April 08,2025 at 19:38:05 UTC from IEEE Xplore. Restrictions apply.
wallet interfaces via DIDComm and uses custom presentation are strictly followed. In the following, we will look at each
requests. Information from presented credentials is mapped component separately:
into the OIDC id_token. Unfortunately, the implementation 1) OpenID Connect Provider: An OpenID Connect
seems to be mostly, if not only, compatible with their BC Provider (OIDC Provider) is a service or software component
Mobile Wallet, and the trust model is unclear. that implements the OIDC protocol to enable secure and
IdP Kit4 from walt.id is another open-source effort and standardized user authentication and authorization. In our ar-
looks promising. From what the documentation5 shows, the chitecture, it is the interface for OIDC clients. At a minimum,
project focuses on OIDC compliance and additionally offers it should support the common OAuth2.0 Authorization Code
sign-in based on Non-Fungible-Token possession. The most flow [5]. The more robust and fully compliant this OIDC
significant downsides seem to lie in the lack of detail regarding Provider is, the better the interoperability with existing OIDC
wallet interaction implementation and the amount of required clients. Since the service provider operates the middleware,
configuration. However, public deployments were unavailable, we do not use scopes beyond the default openid scope. We
and recent builds failed, as the documentation also acknowl- also do not need the OIDC consent phase because a Verifiable
edged. Presentation (VP) already ensures consent.
Moving on to other IAMs, Hong et al. [16] develop an 2) Relying Party Service: The Relying Party Service ad-
architecture that allows sign-in through OAuth 2.0, also used heres to OID4VP with SIOPv2 to request and receive a VP
in OIDC. It is heavily blockchain-focused and requires one from a wallet. OID4VP dictates that a presentation definition
identification smart contract to be deployed per user. This is from the DIF Presentation Exchange (PEX) [18] specification
likely too complex for the average user in the near future and is used to inform the wallet how many credentials with what
leaves the question of who will pay user registration costs. claims are expected. This is not critical for security in our
Since then, the standardization of DIDs has offered more system, but it is necessary to improve the user experience
usable options for mass adoption. because wallets will usually pre-select suitable credentials
Yildiz et al. [17] present an architecture making SSI creden- based on the presentation definition.
tials available for SAML sign-in. The implementation relies on 3) Presentation Definition Generator: The Presentation
Hyperledger Indy and Aries. It supports a cross-device flow Definition Generator creates a presentation definition based
via DIDcomm. That means that the architecture’s SSI-facing on a login policy. The policy specifies one or more credentials
interface is locked into Hyperledger Indy. it expects. For each expected credential, at least one pattern
defines expected claims and trusted issuer. All patterns from
IV. M IDDLEWARE A RCHITECTURE
the policy are turned into input descriptors requesting the pres-
Our proposed middleware design negotiates authentication ence of the claim without specifying filters. The Submission
and authorization between an SSI ecosystem and an OIDC Requirement Feature [18] is used to properly translate that
client. Beyond the scope of an individual sign-in process, only one of the patterns from each expected credential needs
our design is stateless, simplifying maintenance and migration to be fulfilled. A custom array of input descriptors may be
operations. We introduce a one-file configuration to avoid supplied if a service provider requires more control, overriding
the common pitfall of overloading administrators with all the the Presentation Definition Generator.
combined complexity of the middleware interfaces. 4) Verifiable Credential Verifier: The Verifiable Credential
A. Deployment Considerations Verifier’s job is the cryptographic and structural verification
of W3C VCs and VPs according to specification. In addition
The design of the middleware is heavily influenced by its to that, revocation following the W3C’s StatusList2021 [19]
intended deployment model. Acting as an OIDC Provider proposal should be supported. The status list server is optional
to service clients, the middleware has full authority over and operated by the respective issuer that wishes to support
transmitted user information with no accountability. Thus, the revocation. DID resolution must be added as needed. Should
only feasible deployment option is for every service provider a universal DID resolver emerge, it is trivial to incorporate it
to deploy one themselves. Prior work has also reached this here. This whole Verifiable Credential Verifier is a standard
conclusion [10]. Consequently, our architecture is designed to component that can be realized by any of the existing open-
support one sign-in configuration, represented by one login source libraries in the SSI space.
policy. 5) Policy Service: To ensure that presented credentials con-
B. Components tain the required claims and are issued by trusted issuers, the
Policy Service evaluates a VP with respect to the login policy.
The middleware architecture we propose is made up of five
To be accepted, each VC in a submitted VP must be matched
subcomponents that are depicted in Figure 1. Each component
to precisely one of the expected credentials in the login policy.
is a tightly coupled unit of functionality and could likely be its
Additionally, this service also extracts and transforms claim
own library. However, actual implementation choices are up
data. Claims from the VP a user presents must be made
to the individual implementor as long as external interfaces
available via OIDC in a way that is readable by current OIDC
4 https://github.com/walt-id/waltid-idpkit clients. The new vp_token defined in OID4VP [7] could
5 https://docs.walt.id/v/idpkit/getting-started/quick-start be used, but it is infeasible to rely on the quick adoption of

81

Authorized licensed use limited to: BRAC UNIVERSITY. Downloaded on April 08,2025 at 19:38:05 UTC from IEEE Xplore. Restrictions apply.
 Fig. 1. A component diagram of our proposed middleware and its interfaces.

1 openid-vc:// the RPS with the login_id. It is used as the VP challenge

2 ?client_id=<MIDDLEWARE_DID> during the following standardized Presentation Exchange flow.
3 ?request_uri=<BACKEND_URL>/api/presentCredential
4 %3Flogin_id=<CHALLENGE> After step 17, the RPS has received a VP. Following
successful processing, it uses the challenge from that VP
Listing 1: QR code contents for starting a credential exchange to confirm the authentication and authorization to the OIDC
process with a wallet via SIOPv2 and OID4VP. provider. The subject is identified by its DID. Additionally, all
processed claims from the VP are written to the data store to
be accessible during the next phase.
a draft specification that will likely never be supported by At this point, the active role in the sign-in process needs to
many legacy systems depending on OIDC when we design be handed back to the browser. To do so, the RPS has written
for interoperability. Thus, claims need to be transferred into the redirect_uri for the browser to its data store. Using
the established id_token and access_token [2] to work the challenge, the browser periodically requests the redirect to
with all OIDC clients. see if the VP submission has happened yet. When it succeeds,
C. Protocol Integration it executes the redirect in step 29.
Now, the consent phase of the authorization code flow will
One big challenge in engineering our middleware lies in the take place, but as we do not need to ask for consent a second
specifics of the cross-device sign-in flow. As an example, we time, the RPS will automatically complete it. Using the new
will now examine our adaption of perhaps the most common consent_challenge, the RPS can request metadata on
OAuth 2.0 flow: the authorization code flow [5]. Our protocol this consent process from the OIDC provider in step 31. Most
flow can be seen in Figure 2. While not mandatory to our importantly, that includes the subject DID, which is used to
architecture, we assume the use of an existing OIDC Provider retrieve the processed claims that were previously written to
implementation, which is preferable for stability. We have the data store in step 23. Then, the RPS confirms the user’s
slightly simplified some parts while keeping the depiction consent to the OIDC provider and sends the claim data for
close to the technical reality. For example, we have omitted tokens in step 34.
responses for data store interactions.
Finally, the sign-in procedure concludes as usual for an
At the start of the depicted flow, the user is assumed to
authorization code flow from step 35 and on. The only
have opened a service website hosted by the OIDC client web
noteworthy exception is that the middleware never provides
server in their browser. When requesting to sign in, the user
a refresh_token because it must not depend on caching
is redirected to our login page. It features a QR code that
critical identity data and should remain stateless in the larger
contains the necessary information to involve the smartphone
context.
wallet in the flow, which is depicted in Listing 1.
The request_uri tells the wallet where to fetch a pre-
D. Login Policy Definition
sentation request. Notably, we add a custom query parameter
called login_id to use as a challenge for the following A login policy is our central configuration format for the
presentation exchange and to allow the Relying Party Service entire middleware. For illustration purposes, a simple example
(RPS) backend to know which browser and wallet are involved policy is depicted in Listing 2. It is a JSON array of objects
in the same sign-in procedure. When the wallet asks for a that describe an expected VC each and are indexed by a
presentation request in step 9, it also automatically provides credentialId. Our example expects exactly one VC. Since

82

Authorized licensed use limited to: BRAC UNIVERSITY. Downloaded on April 08,2025 at 19:38:05 UTC from IEEE Xplore. Restrictions apply.
 Fig. 2. An only slightly simplified sign-in procedure with our middleware using the authorization code flow. At the start of the presented sequence, we
assume that the user has accessed the web page provided by the OIDC client. Names of variables and endpoints have been chosen to be descriptive.

a service may want to accept VCs of different types from dif- necessary if two trusted issuers use different claim names
ferent issuers that still contain the same relevant information, for the same piece of information, which should be unified
each expected VC is characterized by a list of patterns. Once for the downstream service. Every claim has a claimPath,
again, our simple example only has one pattern. which is a JSONPath. Optionally, newPath provides a new
Each pattern lists claims identified by JSONPaths following JSONPath for the claim value inside the corresponding OIDC
the Presentation Exchange specification [18], which must token. It defaults to the last element of the claimPath and, if
begin from the root element. A VC matches a pattern if and explicitly specified, must always point to exactly one location.
only if the issuer matches and all required claims are present. The target token is specified using the token property, which
By default, every claim is assumed to be required. Because defaults to the access_token if not present. In the case that
existing services incorporating an OIDC client likely depend a claimPath points to more than one value, a newPath is
on standard OIDC claim names, transferring claims might not required. All claims in the original path are aggregated as a
be sufficient, leading us to support renaming. This is also JSON object and indexed only by their ultimate JSONPath

83

Authorized licensed use limited to: BRAC UNIVERSITY. Downloaded on April 08,2025 at 19:38:05 UTC from IEEE Xplore. Restrictions apply.
1 [{ 1 "credentialSubject": {
2 "credentialId": "email_vc", 2 "id": "did:key:z6M...",
3 "patterns": [{ 3 "email": "[email protected]",
4 "issuer": "did:web:emailvalidator.example.com", 4 "type": "EmailPass",
5 "claims": [{ 5 "issuedBy": { "name": "Altme" }
6 "claimPath": "$.credentialSubject.email", 6 }
7 "token": "id_token"
8 }],
9 "constraint": { Listing 3: The credentialSubject key in an Altme Proof
10 "op": "equalsDID",
11 "a": "$VP.proof.verificationMethod", of email VC with shortened id field.
12 "b": "$.credentialSubject.id"
13 }
14 }]
15 }] E. Limitations
First, services using our middleware only have access to
Listing 2: An example login policy that expects one VC, user attributes, not an interactive wallet connection. So, if a
which is certifying the subject’s email address. The constraint service requires a wallet interaction to, for instance, obtain
enforces a simple holder binding. a user signature, relying on OIDC might not be advisable.
Similarly, requesting additional VCs after a user is signed in is
not supported. Second, any implementation of our architecture
element. That object is written to the newPath. must make choices about the DID methods, signatures, and
A constraint may be defined for each pattern to provide VC formats it wants to support. It may never be possible to
conditions under which a VP is accepted that go beyond a develop a middleware that supports all SSI ecosystems and
normal VP verification. We define a constraint as a JSON ob- flavors.
ject containing an operator code op and usually two operands.
Every constraint can only return a boolean. That makes the V. P RELIMINARY E VALUATION
constraints easily extensible should the need arise in the future. We evaluated our design by implementing it and testing
The expressiveness of the constraint definition is ensured via different sign-in scenarios. For our implementation, we were
the logical operators and, or, and not, which allow complex looking for a robust and configurable open-source OIDC
combinations of multiple other constraints. Beyond the logical Provider. We ended up choosing Ory Hydra6 . Its compliance is
operators, there are the following ones: officially verified by the OpenID Foundation. Setting up Hydra
1) equals Strictly compares two string values. Takes two is convenient via Docker7 and the sign-in flow implementation
JSONPaths or a JSONPath and a string. makes it possible to redirect to custom web services for login
2) startsWith Evaluates whether string a starts with b. and consent8 . That allows us to build our proof of concept
Takes two JSONPaths or a JSONPath and a string. without touching Hydra’s source code.
3) endsWith Evaluates whether string a ends with b. Takes We implemented all components of the middleware apart
two JSONPaths or a JSONPath and a string. from the OIDC Provider from the ground up as one web
4) matches Evaluates whether string a has a match for service and called it vclogin. This service connects to Hydra by
regular expression b. Takes a JSONPath and a string. using its APIs for custom login and consent services. We chose
5) equalsDID Compares two DIDs or DID URLs by only to build with Next.js9 , as it allows us to combine user-facing
their DID. Takes two JSONPaths or a JSONPath and a web pages with API routes in a single code base. Furthermore,
string. we use a PostgreSQL10 Database for Hydra and a Redis11 as a
short-term data store for vclogin. The Redis store only acts as
Constraints must be evaluated after a VP’s VCs have been
temporary storage, and all data is set to expire within minutes.
matched to the corresponding patterns. That ensures that the
For our use case, the PostgreSQL database can also be reset
constraint of one VC can address the contents of another.
without effect. Thus, the entire middleware implementation is
Especially in scenarios where more than one VC is expected,
essentially stateless and can be migrated without a database
it might be necessary to define how these VCs are related to
migration. Our final code base is available online12 as open-
each other. To make other credentials addressable, we extend
source software.
the JSONPaths definition. Directly after the root element
For practical testing, we used the Altme Wallet13 . It is
indicator $, a credentialId may be inserted to make the
open-source, actively worked on, and available on app stores
path relative to that matching VC’s root. The identifier VP is
for convenient installation. For our testing, it is essential that
reserved to refer to the root of the VP. Our example in Listing
2 uses a single constraint to enforce that the signer of the 6 https://github.com/ory/hydra
VP is also the subject of the presented VC, which constitutes 7 https://www.docker.com/
8 https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow
a simple holder binding. In case of a constraint validation
9 https://nextjs.org/
error, for example, an unresolvable JSONPath, this specific 10 https://www.postgresql.org/
constraint validation must fail and return false. Only if the 11 https://redis.io/
validation of a pattern’s constraint returns false at its root 12 https://github.com/GAIA-X4PLC-AAD/ssi-to-oidc-bridge

does the login policy reject a VP. 13 https://github.com/TalaoDAO/AltMe

84

Authorized licensed use limited to: BRAC UNIVERSITY. Downloaded on April 08,2025 at 19:38:05 UTC from IEEE Xplore. Restrictions apply.
 [2] OpenID Foundation, “OpenID Connect Core 1.0 incorporating errata set
1 [{ 1,” https://openid.net/specs/openid-connect-core-1 0.html, 2014, (Ac-
2 "credentialID": "one", cessed 02-12-2023).
3 "patterns": [{ [3] M. Sporny, D. Longley, and D. Chadwick, “Verifiable Credentials Data
4 "issuer": "did:web:app.altme.io:issuer", Model v1.1,” https://www.w3.org/TR/vc-data-model/, 2022, (Accessed
5 "claims": [{
6 "claimPath": "$.credentialSubject.email",
03-12-2023).
7 "token": "id_token" [4] M. Sporny, D. Longley, M. Sabadello, D. Reed, O. Steele, and
8 }] C. Allen, “Decentralized Identifiers (DIDs) v1.0,” https://www.w3.org/
9 }] TR/did-core/, 2022, (Accessed 03-12-2023).
10 }] [5] D. Hardt, “The OAuth 2.0 Authorization Framework,” RFC 6749, Oct.
2012. [Online]. Available: https://www.rfc-editor.org/info/rfc6749
[6] K. Yasuda, T. Lodderstedt, D. Chadwick, K. Nakamura,
Listing 4: A login policy accepting a VC issued by Altme and J. Vercammen, “Openid for verifiable credentials,” https:
containing an email. //openid.net/wordpress-content/uploads/2022/06/OIDF-Whitepaper
OpenID-for-Verifiable-Credentials-V2 2022-06-23.pdf, 2022,
(Accessed 02-12-2023).
[7] O. Terbu, T. Lodderstedt, K. Yasuda, and T. Looker, “OpenID
the wallet supports OID4VP with SIOPv2. Altme offers the for Verifiable Presentations - draft 18,” https://openid.net/specs/
issuance of a Proof of email JSON-LD VC, which we used openid-4-verifiable-presentations-1 0-ID2.html, 2023, (Accessed 03-
12-2023).
in our initial test. The relevant claims from that VC are [8] K. Yasuda and M. Jones, “Self-Issued OpenID Provider v2,” https:
shown in Listing 3. It is signed by a did:web and contains //openid.net/specs/openid-connect-self-issued-v2-1 0-ID1.html, 2022,
a StatusList2021 entry. We used the test client included in (Accessed 03-12-2023).
[9] M. Kuperberg and R. Klemens, Integration of Self-Sovereign Identity
Hydra’s command line interface (CLI) for testing14 . It hosts into Conventional Software Using Established IAM Protocols: A Survey.
a website with a sign-in button and shows session metadata Gesellschaft für Informatik e.V., 2022.
upon successful sign-in. The browser used does not matter. [10] A. Grüner, A. Mühle, and C. Meinel, “Analyzing Interoperability and
Portability Concepts for Self-Sovereign Identity,” in 2021 IEEE 20th
The login policy we used can be found in Listing 4. To perform International Conference on Trust, Security and Privacy in Computing
the test, we started our middleware and used Hydra’s CLI and Communications (TrustCom). Shenyang, China: IEEE, Oct. 2021,
to register and start the test client. This successful first test pp. 587–597.
[11] H. Yildiz, A. Küpper, D. Thatmann, S. Göndör, and P. Herbke, “A
indicates that our end-to-end design is feasible: Tutorial on the Interoperability of Self-sovereign Identities,” Aug. 2022.
1) Click ”Authorize application” in the browser. [12] F. Schardong and R. Custódio, “Self-Sovereign Identity: A Systematic
2) Scan the QR code on the next page with the wallet. Review, Mapping and Taxonomy,” Sensors, vol. 22, no. 15, p. 5641,
Jan. 2022.
3) Select one email VC from the list and press ”Present” [13] A. Grüner, A. Mühle, and C. Meinel, “An Integration Architecture to
in the wallet. Enable Service Providers for Self-sovereign Identity,” in 2019 IEEE
4) On the browser, get redirected to a page showing the 18th International Symposium on Network Computing and Applications
(NCA). Cambridge, MA, USA: IEEE, Sep. 2019, pp. 1–5.
received session tokens for validation. [14] ——, “ATIB: Design and Evaluation of an Architecture for Brokered
Self-Sovereign Identity Integration and Trust-Enhancing Attribute Ag-
VI. C ONCLUSION gregation for Service Provider,” IEEE Access, vol. 9, pp. 138 553–
138 570, 2021.
We have designed, implemented, and initially tested a [15] Z. A. Lux, D. Thatmann, S. Zickau, and F. Beierle, “Distributed-Ledger-
middleware architecture that can simplify the adoption of based Authentication with Decentralized Identifiers and Verifiable Cre-
SSI for sign-in procedures by leveraging the existing imple- dentials,” Jun. 2020.
[16] S. Hong and H. Kim, “VaultPoint: A Blockchain-Based SSI Model that
mentations and expertise available for OIDC. The results are Complies with OAuth 2.0,” Electronics, vol. 9, no. 8, p. 1231, Aug.
promising. Yet, extended validation of usability, performance, 2020.
and security is necessary. For further future work, finding a [17] H. Yildiz, C. Ritter, L. T. Nguyen, B. Frech, M. M. Martinez, and
A. Küpper, “Connecting Self-Sovereign Identity with Federated and
mapping that can bring our login policy’s constraints into the User-centric Identities via SAML Integration,” in 2021 IEEE Symposium
Presentation Exchange’s presentation definition would enhance on Computers and Communications (ISCC). IEEE, Sep. 2021.
the user experience by providing even better guidance upon [18] D. McGrogan, G. Cohen, O. Steele, W. Chang, D. Chadwick,
J. Hensley, N. Klomp, and A. Kesselman, “DIF Presentation Ex-
VC selection in a wallet. Also, while our architecture and login change 2.0.0,” https://identity.foundation/presentation-exchange/spec/v2.
policy language should theoretically work with JWT-VC proof 0.0/, 2022, (Accessed 03-12-2023).
formats, we have not confirmed that. [19] D. Longley and M. Sporny, “Status List 2021 —
w3.org,” https://www.w3.org/community/reports/credentials/
ACKNOWLEDGMENT CG-FINAL-vc-status-list-2021-20230102/, 2023, (Accessed 01-
12-2023).
This work has been funded by the German Federal Ministry
of Economic Affairs and Climate Action (BMWK) under
grant 19S21006N. The responsibility for the content of this
publication lies with the authors.
R EFERENCES
[1] C. Allen, “The path to self-sovereign identity,” 2016, (Accessed
21-11-2023). [Online]. Available: http://www.lifewithalacrity.com/2016/
04/the-path-to-self-soverereign-identity.html

14 https://www.ory.sh/docs/cli/ory-perform-authorization-code

85

Authorized licensed use limited to: BRAC UNIVERSITY. Downloaded on April 08,2025 at 19:38:05 UTC from IEEE Xplore. Restrictions apply.