Rust implementation of the OpenID4VC standards. The library will offer implementations for SIOPv2, OpenID4VP and OpenID4VCI.
Home Page: https://www.impierce.com
License: Apache License 2.0
Support proper IdToken validation as described in the spec: https://openid.bitbucket.io/connect/openid-connect-self-issued-v2-1_0.html#name-self-issued-id-token
Crucial step in the SIOPv2 flows.
https://openid.bitbucket.io/connect/openid-connect-self-issued-v2-1_0.html#name-self-issued-id-token
Specifically the SIOPv2, OID4VC and OID4VCI crates need to be properly split. All common/shared code should be migrated to a new crate: oid4vc-core or oid4vc-common.
Whenever SIOPv2 or OID4VC should be used in unison, their respective feature flags should be used.
This is necessary in order for SIOPv2 to be used with and without OID4VP and vice versa.
No response
DIF Presentation Exchange describes multiple features that can be added to the basic presentation exchange process: https://identity.foundation/presentation-exchange/spec/v2.0.0/#features
#21 needs to be merged first.
Adding support for all or some of them will increase the interoperability of this library.
https://identity.foundation/presentation-exchange/spec/v2.0.0/#features
There is a multitude of different DID Methods, however, not all Relying Parties and Providers will necessary will have all of them implemented. This library will provide the Subject trait that can be used to implement custom DID Methods. Both the RelyingParty, as well as the Provider should be able to ingest multiple Subject Syntax Types.
SIOPv2 defines two Subject Syntax Types:
JWK Thumbprint subject syntax type: When this type is used, the sub claim value must be the base64url encoded representation of the JWK thumbprint of the key in the sub_jwk claim, and sub_jwk must be included in the Self-Issued Response.
Decentralized Identifier (DID) subject syntax type: When this type is used, the sub value must be a DID as defined in [DID-Core], and sub_jwk must not be included in the Self-Issued Response. The subject syntax type must be cryptographically verified against the resolved DID Document as defined in the SIOPv2 ID Token validation section.
The user of this library should be able to select their preferred subject syntax type both as a Relying Party as well as for a Provider.
By adding support for Subject Syntax Types, this SIOP library will be able to generate and validate ID Tokens that conform to the latest version of the SIOP specification. This will enhance the interoperability of our SIOP implementation with other SIOP-compliant systems and improve the security and reliability of the authentication process.
https://openid.net/specs/openid-connect-self-issued-v2-1_0.html#name-subject-syntax-types
SubjectSyntaxType's to the Provider.SubjectSyntaxType's to the Relying Party.We will fork the Sphereon demo website's GitHub repository and build a test framework. This step will involve setting up a local development environment, running automated tests, and debugging any issues that arise. Some of the default settings in the dotenv files of both the frontend and backend need to be tweaked by adding a did:key did and its private key.
A script should be provided that will spin up the demo website when tests are performed.
In order to test the validity of the library, we need to test the interoperability with other SIOP implementations.
The Submission Requirement Feature introduces extensions enabling Verifiers to express what combinations of inputs must be submitted to comply with its requirements for proceeding in a flow (e.g. credential issuance, allowing entry, accepting an application).
See #32
#32
https://identity.foundation/presentation-exchange/spec/v2.0.0/#submission-requirement-feature
Support the validation of VP Tokens as described here: https://openid.bitbucket.io/connect/openid-4-verifiable-presentations-1_0.html#name-vp-token-validation
Some of the validation rules are described in the DIF Presentation Exchange spec: https://identity.foundation/presentation-exchange/spec/v2.0.0/#presentation-submission
Crucial step in the OID4VP flows.
https://openid.bitbucket.io/connect/openid-4-verifiable-presentations-1_0.html#name-vp-token-validation
https://identity.foundation/presentation-exchange/spec/v2.0.0/#presentation-submission
Fork the Sphereon demo website and alter some variables so that it suits our needs (alter the default DID method to did:key, add test private keys, etc) and so that it can be added as an integration test.
The demo website follows the following steps:
redirect_uri is presented in the form of a QR Code (by the relying party).id_token and sends it to the Relying Party's redirect_uriIn order for this integration to work some Request parameters need to be added as well, such as the request_uri and the registration parameter.
In order to test the validity of the library, we need to test the interoperability with other SIOP implementations.
Depends on #2
Sphereon demo website
+--------------+ +-----------+ +-------------------+
| User | | Wallet | | Credential Issuer |
+--------------+ +-----------+ +-------------------+
| | |
| | (1) User provides information required |
| | for the issuance of a certain Credential |
|-------------------------------------------------------------------->|
| | |
| | (2) Credential Offer (Pre-Authorized Code) |
| |<---------------------------------------------------|
| | (3) Obtains Issuer's Credential Issuer metadata |
| |<-------------------------------------------------->|
| interacts | |
|--------------->| |
| | |
| | (4) Token Request (Pre-Authorized Code, pin) |
| |--------------------------------------------------->|
| | Token Response (access_token) |
| |<---------------------------------------------------|
| | |
| | (5) Credential Request (access_token, proof(s)) |
| |--------------------------------------------------->|
| | Credential Response |
| | (credential(s)) |
| |<---------------------------------------------------|
Figure 2: Issuance using Pre-Authorized Code Flow
No response
Refactor RequestUrl so that it can handle a requests' protocol, and (sub)domain dynamically, as mentioned here: #17 (comment)
At the moment request urls are statically prefixed with siopv2://idtoken. This protocol and (sub)domain part of the url should be dynamic though, and therefore the RequestUrl enum should be refactored, possible by converting it to a struct instead.
No response
No response
Support Static Configuration Values that can be used by the RP to construct it's Authorization Requests.
No response
+--------------+ +-----------+ +-------------------+
| User | | Wallet | | Credential Issuer |
+--------------+ +-----------+ +-------------------+
| | |
| interacts | |
|--------------->| |
| | (1) Obtains Issuer's Credential Issuer metadata |
| |<-------------------------------------------------->|
| | |
| | (2) Authorization Request |
| | (type(s) of Credentials to be issued) |
| |--------------------------------------------------->|
| | |
| User Authentication / Consent |
| | |
| | (3) Authorization Response (code) |
| |<---------------------------------------------------|
| | |
| | (4) Token Request (code) |
| |--------------------------------------------------->|
| | Token Response (access_token) |
| |<---------------------------------------------------|
| | |
| | (5) Credential Request (access_token, proof(s)) |
| |--------------------------------------------------->|
| | Credential Response |
| | (credential(s) OR transaction_id) |
| |<---------------------------------------------------|
Figure 1: Issuance using Authorization Code Flow
No response
The JSON-LD Framing Feature extends Presentation Definition to support extended with the JSON-LD document framing.
See #32
#32
https://identity.foundation/presentation-exchange/spec/v2.0.0/#json-ld-framing-feature
Add a new DidMethod variant for the did:key method. It should follow a similar implementation to the did:iota method (by implementing the Subject trait.
The did:iota is not (yet) widely accepted by relying parties. Therefore, we should add support for the did:key method is supported by the DIF Universal Resolver and is therefore supported by this SIOP library. There is already a rust implementation for did:key
When the did:key method is properly implemented, this will add validity to our own SIOP implementation.
DIF Universal Resolver
https://github.com/RadicalLedger/did-siop-lib
did:key in rust
DidMethod Key which implements the Subject traitThe Relational Constraint Feature extends the Input Descriptor Object constraints object with additional properties.
See #32
#32
https://identity.foundation/presentation-exchange/spec/v2.0.0/#relational-constraint-feature
We will implement JWT decoding and validation for the Provider struct. This will involve decoding the JWT and verifying its signature to ensure its authenticity. Additionally, we will perform other validation checks such as checking the issuer and audience claims.
When a SiopRequest is particularly large (for example when it includes a Presentation Definition for Verifiable Presentations, or many claims) a Relying Party may choose to send its request by value by utilizing the request_uri. The actual SiopRequest that can be retrieved by following this redirect uri may or may not be encoded as a JWT. Therefore, the Provider should be capable of decoding and validation JWT's
Provider struct.Make the IdToken struct fully feature complete as mentioned here: #17 (comment)
Also, implement a builder pattern either specifically for IdToken and/or for a Token enum with (at least) the IdToken(IdToken) and VpToken(VpToken) variants. They should directly map to the already existing ResponseType enum that's being used in the SiopRequest struct.
The IdToken should be fully feature complete in order to be 100% conform to the SIOPv2 specification.
The IdToken can have several different kind of claims, such as the openid standard claims, jwt registered claims, and other claims. The following specifications need to be followed:
No response
Add initial support for verifiable presentations.
This Issue involves adding support for the vp_token response_type and presentation_definition parameter in the SIOP library, as described in the OpenID for Verifiable Presentations (OpenID4VP) specification. When the vp_token response type is set, the Provider should generate a presentation of verifiable credentials based on the presentation_definition parameter in the request. The Relying Party should then be able to verify the presentation and authenticate the user based on the claims presented.
This implementation should initially be following the IOTA DID method.
Apart from the SIOPv2 specification, this library should also be able to support the OpenID for Verifiable Presentations specification. The initial implementation as described above will also allow for testing this library against external Client libraries.
OpenID for Verifiable Presentations (OpenID4VP) specification
#4
PresentationDefinition struct that can be deserialized from a SiopRequestVerifiablePresentation struct that can be build from a PresentationDefinitionpresentation_submission parameter alongside the new vp_token in the SiopResponseopenid4vp feature flagWe will add support for the registration parameter, which allows clients to provide some metadata about themselves to the Provider. This will help to simplify the process of requesting access to protected resources. More details: SIOPv2 section 7.2.2.
Members of the registration parameter are needed for the Provider to know if it is compatible with the Relying Party. Example of a registration parameter in a decoded JWT:
"registration": {
"id_token_signing_alg_values_supported": [
"EdDSA",
"ES256",
"ES256K"
],
"request_object_signing_alg_values_supported": [
"EdDSA",
"ES256",
"ES256K"
],
"response_types_supported": [
"id_token"
],
"scopes_supported": [
"openid did_authn"
],
"subject_types_supported": [
"pairwise"
],
"subject_syntax_types_supported": [
"did",
"did:ethr",
"did:key",
"did:ion",
"did:jwk"
],
"vp_formats": {
"jwt_vc": {
"alg": [
"EdDSA",
"ES256K"
]
},
"jwt_vp": {
"alg": [
"ES256K",
"EdDSA"
]
}
}
registration parameter and its members.We need to add support for the Authorization Code Flow as described in SIOPv2 and in section 3.1.2 of the OIDC-core standard. The Authorization Code Flow is summarized as follows:
We should be able to add support for the Authorization Code Flow in the SIOP Requests, and the Provider should be able to handle the Authorization Code and generate the ID Token and Access Token accordingly. The library should also be able to perform the necessary token exchange requests to obtain the tokens from the Provider.
The Authorization Code Flow is an important OAuth 2.0 flow that provides a more secure way of obtaining access tokens compared to the Implicit Flow. This flow is widely used in many applications and is also supported by major identity providers, such as Google and Microsoft. By adding support for the Authorization Code Flow in SIOPv2, we can provide users and developers with a more secure and standardized way of obtaining access tokens, which is crucial for the protection of sensitive user data. Additionally, this will enable more seamless integration of SIOPv2 with other OAuth 2.0 based systems, providing greater flexibility in application design and implementation.
SIOPv2
section 3.1.2 of the OIDC-core standard
Providertoken_endpoint for the ProviderThe documentation of the individual crates should be easy to understand for first-time users. Simple diagrams on how the individual crates are related should be included.
Improve developer experience
No response
Rename repo to oid4vc.
Make sure all depending crates follow the name change.
Rename repo to oid4vc in order to match the crates name.
No response
The error response must be made in the same manner as defined in Section 3.1.2.6 of [OpenID.Core].In addition to the error codes defined in Section 4.1.2.1 of OAuth 2.0 and Section 3.1.2.6 of [OpenID.Core], this specification also defines the following error codes:
user_cancelled: End-User cancelled the Authorization Request from the RP.
registration_value_not_supported: the Self-Issued OP does not support some Relying Party parameter values received in the request.
subject_syntax_types_not_supported: the Self-Issued OP does not support any of the Subject Syntax Types supported by the RP, which were communicated in the request in the subject_syntax_types_supported parameter.
invalid_registration_uri: the client_metadata_uri in the Self-Issued OpenID Provider request returns an error or contains invalid data.
invalid_registration_object: the client_metadata parameter contains an invalid RP parameter Object.
Other error codes MAY be used.Note that HTTP error codes do not work in the cross-device Self-Issued OP protocol flows.
Essential part of the same-device flow.
https://openid.net/specs/openid-connect-self-issued-v2-1_0.html#section-10.3
OpenID.Core]
Add a Builder for RequestUrl, as well as serialization and deserialization to and from a request literal string.
This will improve the construction of new SiopRequests.
[Self-Issued OpenID Provider Authorization Request](https://openid.net/specs/openid-connect-self-issued-v2-1_0.html#name-self-issued-openid-provider-a)
See https://identity.foundation/presentation-exchange/spec/v2.0.0/#credential-status-constraint-feature
See #32
#32
https://identity.foundation/presentation-exchange/spec/v2.0.0/#credential-status-constraint-feature
The library should be able to add the request for claims in the SIOP Requests and the Provider should be able to handle those claims accordingly. As specified in the OICD-core standard, claims can be requested by the Relying Party using the claims request parameter.
There are two types of claims:
Both of them need to be implemented.
In OpenID Connect, a claim is a piece of information about the user, such as their name or email address, that the Relying Party can request from the OpenID Provider. The claims request parameter is used by the Relying Party to specify which claims it wants to receive in the ID token or UserInfo response.
The claims parameter value is a JSON object that describes the set of requested claims, including the name of the claim and any additional parameters needed to process the claim. The OpenID Provider may or may not provide the requested claims based on the user's consent and the authorization policies of the Provider.
By adding support for the claims request parameter, our library will allow Relying Parties to request specific claims about the user and receive them in a standardized way, making it easier for them to integrate with our library and comply with OpenID Connect standards.
OICD-core claims specification
SIOP-v2
OpenID4VP
We will implement support for the request_uri parameter, which allows clients to send a URI reference to a SiopRequest represented as a signed JWT token.
When a SiopRequest is particularly large (for example when it includes a Presentation Definition for Verifiable Presentations, or many claims) a Relying Party may choose to send its request by value by utilizing the request_uri. The Provider may follow this URI in order to retrieve the actual SiopRequest as a signed JWT.
request_uri parameter in the Provider struct when generating a ResponseThe Retention Feature extends the Input Descriptor Object's field object, allowing a Verifier to indicate it will retain the submitted value for the specific field. It is currently presented to support mDL systems, and may be deprecated in the future or moved to a separate specification for more robust mDL interoperability at a later time.
See #32
#32
https://identity.foundation/presentation-exchange/spec/v2.0.0/#retention-feature
In the SIOPv2 cross-device scenario, the Relying Party converts its SIOP Request into a QR Code which presented on one device so that it can be scanned using a second device. The Provider should be able to read that QR Code and construct it back into the original request again.
Adding support for QR scanning in the cross-device scenario described in SIOPv2 can greatly improve the user experience and simplify the authentication process. Instead of manually entering authentication codes, users can simply scan a QR code displayed on one device with another device's camera to authenticate. This is especially beneficial in scenarios where users need to authenticate across different devices, such as when logging into a website on a desktop computer with a mobile phone.
QR code scanning is already a familiar and widely used technology for mobile devices, and it can greatly simplify the authentication process by eliminating the need for manual input of complex codes or URLs. By adding support for QR code scanning, the SIOP library can provide a more user-friendly authentication experience, which can increase user adoption and reduce the risk of authentication errors. Additionally, QR code scanning can improve security by providing a more convenient and secure way to authenticate, reducing the likelihood of password sharing or other security risks.
Cross-Device Self-Issued OpenID Provider Request
RelyingPartyProviderWe need support for the Implicit Flow for SIOPv2 as described in SIOPv2 as well as in section 7 of the OIDC-core standard. The Implicit Flow is summarized as follows:
redirect_uri by a direct HTTP POST request.The Implicit Flow is a widely used flow in OpenID Connect, and its support is necessary for our SIOP implementation to be fully compliant with the specification. By implementing the Implicit Flow, we can ensure that our SIOP Provider is able to generate and sign ID Tokens that can be securely transmitted to Relying Parties. This will also expand the interoperability of our SIOP Provider with other OpenID Connect compliant systems.
Provider struct that can validate SIOP Requests and create and sign SIOP Responses (including ID Token).RelyingParty struct that can create and present a SIOP Request as well as validate SIOP Responses.The JWK Thumbprint subject syntax type is a type of Subject Syntax Type used in the Self-Issued OpenID Provider (SIOP) protocol flow. In this syntax type, the sub (subject) claim value in the ID Token issued by the Self-Issued OP is the base64url encoded representation of the JWK thumbprint of the key in the sub_jwk (subject key) claim. The sub_jwk claim is included in the Self-Issued Response and contains the public key used by the Self-Issued OP to sign the ID Token.
This syntax type allows the Relying Party (RP) to verify the signature on the ID Token using the JWK thumbprint of the key, without having to retrieve the JWK set from the Self-Issued OP. The JWK thumbprint is a compact representation of the public key and can be used as a unique identifier for the key. This approach reduces the size of the SIOP request and response messages and simplifies the processing for the RP.
The JWK Thumbprint subject syntax type is a mandatory requirement for compliant implementation of the Self-Issued OpenID Provider (SIOP) protocol, as described in the SIOPv2 specification. Therefore, adding support for this subject syntax type will ensure that this SIOP library is compliant with the latest standards and can interoperate with other compliant SIOP implementations.
SIOPv2 JWK Thumbprint
JWK Thumbprint specification
SubjectSyntaxType as a method of signing the SIOP Response (by the Provider)RelyingParty to validate a SIOP Response
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.