Search code examples
openid-connecthyperledger-indydecentralized-identitydecentralized-identifiers

OIDC cloud agent vs SIOP edge agent


We are starting a POC (proof of concept) with Decentralized Identity (DID) and a got a document talking about the authentication method to use:

OIDC cloud agent vs SIOP edge agent.

I don't understand what is that two stuff? and also what are the advantages or disadvantages of using one or another.

I know OpenId Connect but not these two, any explanation or link to read will be much appreciated.

Thanks


Solution

  • This answer assumes you know a fair bit about Indy, Aries, DIDs, verifiable credentials and OIDC. I know a lot about the first set of topics, but am not an expert on OIDC, so bear with me :-).

    SIOP (Self-Issued OpendID Connection Provider) is a standard extension to OIDC, althought it is not implemented by most of the IAM vendors. When implemented, an OIDC Relying Party (RP) can use the SIOP protocol to directly contact a DID holder (say, an Identity Wallet) and get back a verified identifier using a standard OIDC protocol. A project (Interop Project) at the Decentralized Identity Foundation (DIF) is using SIOP to implement DID Authentication. There is an article about the approach here - https://medium.com/decentralized-identity/using-openid-connect-with-decentralized-identifiers-24733f6fa636. The interop project can be found here: https://github.com/decentralized-identity/interop-project

    An alternative that we are working on at British Columbia (BC) Gov with Mattr Global (New Zealand) uses an OIDC cloud agent to implement a standard OIDC Identity Provider (OP) that talks OIDC on one side, and uses a DID protocol (DIDComm) on the other side to talk to a Verifiable Credential holder (again, an Identity Wallet). We're using a standard OIDC client library on one side to receive authorization requests from the RP, and then (using HTTP) to send requests to an Aries Agent (based on Indy) to interact with the Identity Wallet (itself an Aries Agent - or at least one that talks DIDComm) to request a proof, and to receive back the proof. The OIDC library then takes the data from the claims, maps them into an OIDC token to return to the RP. The implmentation assumes that the RP and IdP (combination of OIDC client library and Aries Agent) are operated by the organization requesting the authorization.

    This link has a picture of what the two implementation look like: https://github.com/decentralized-identity/interop-project/issues/16#issuecomment-521130043

    Note that the SIOP implementation is about verifying DIDs, while the OIDC Agent implementation is focused on verifiying claims from verifiable credentials (VC). We are thinking that a degenerative case of the VC authorization is proof of a DID, so the OIDC Agent approach may be able to handle both cases.

    There is a good discussion/summary of the pros and cons of the approaches here: https://github.com/decentralized-identity/interop-project/issues/9

    The work we (BC Gov and Mattr Global) is here: https://github.com/bcgov/vc-authn-oidc