Verifiable Credentials with Transmute and Okta
Transmute’s products bridge the gap between established identity providers (IDPs) and decentralized identity technology. In this second in a series of posts we share more details about how we work with Okta to support and share verifiable credentials.
Okta provides a mechanism for adding custom claims to id_tokens and access_tokens: Hooks and Custom Authorization Servers. These components can enable automated integrations with emergent technology including decentralized identifiers and verifiable credentials.
In this post we’ll take a quick look at how you can leverage these features with Transmute to automate Enterprise Agent activities. Key areas include self service registration hooks and custom claim hooks.
Self Service Registration Hooks
Okta supports self service registration and custom claim hooks. You can review details of those features here, and then continue reading below about Transmute’s enterprise agent applications.
Enterprise Agent Authorization
Using hooks, the Okta Self Service Registration can be extended to support DID Proofing. In this case, the user already has a DID and wants to create an Okta account which is linked to it. The user will retain control of their DID, and Okta will retain control of the universal directory account. As part of this process, a key which is linked to the Okta universal directory will be added to the DID document at the discretion of the registering user. In Transmute we call this process Enterprise Agent Authorization, since Okta (or another Identity Provider depending on customer needs) will be used as the authentication mechanism for leveraging the associated DID on behalf of the user.
Fully Managed Enterprise Agents
Most enterprise users won’t have a DID when they first arrive to a self service registration page. In this case, the hook will create a fully managed DID for the user, and link that DID to their Universal Directory record. For example, one configuration that Transmute supports is that Okta will be used to secure access to all of the keys related to this DID, and the user will not control any aspect of the DID. Transmute also supports modified configurations of the Enterprise Agent Authorization flow that place the user in control of the DID.
Custom Claim Hooks
VC Conversion
Existing systems that rely on custom claims on id_tokens or access_tokens may not understand the verifiable credential (VC) data format or DIDs. In these cases, it’s often desirable to convert a verifiable credential to a normal id_token claim. In order to do this, a hook is used to act as a VC verifier. The credential in question is verified and at the discretion of the hook implementer a standard claim can be added to the desired token. It’s important to note that the hook is responsible for ensuring that the DID associated with the VC is the same DID that is associated with the soon-to-be-modified token, and that the credential is currently valid. Once this translation process is complete, existing services can leverage OIDC / OAuth infrastructure without worrying about DIDs or VCs.
VC Injection
Some systems would prefer to process a VC or may wish to challenge the linked DID in a process outside of an Okta flow (such as authorizing a monetary or data transfer). In these cases it is desirable for the VC to be embedded in the id_token. The hook is responsible for verifying the credential and ensuring it is being attached to the correct token, but does not need to convert the credential to another format. APIs which rely on the token can now access the VC directly and leverage it as needed.
Conclusion
Integrations between IDPs and APIs that rely on them are critical to reducing the friction associated with adopting the security benefits afforded by DIDs, VCs, and DLT. Okta provides a suite of tools which make these integrations painless. Transmute leverages these tools to provide a fast and friendly experience for completing verifiable business workflows.
