OIDC4VP profile for Login-with-IOTA
Last updated
Was this helpful?
SSI Kit
Last updated
Was this helpful?
We apologize that our current implementation does not yet support the Stardust Upgrade from IOTA. As such, you cannot issue or verify credentials associated via a did:iota. Please refer to our for more information on when our products will be updated to include this latest changes.
Authors: Severin Stampler () December 2022
Login-with-IOTA is defined as a profile of the OpenID Connect for Verifiable Presentations specification [], which defines the protocol for authorization using SSI, based on top of OAuth 2.0 [] and introduces protocol extensions for the presentation of claims via Verifiable Credentials []. In this document we will describe the specifics of using the OIDC4VP protocol in the scope of Login-with-IOTA to ensure compatibility with the IOTA identity framework [].
The IOTA identity framework [] defines a custom DID method [], based on the public key of the user account. The key material used is an EdDSA/Ed25519 [] key pair.
To ensure compatibility with the IOTA identity framework [], the issuers and holders of verifiable credentials should use a did:iota for issuance and as credential subject.
The credentials used by the IOTA identity framework [] are in line with the W3C specification for Verifiable Credentials []. Every type of credential, that is compatible with the W3C specification, should in theory be supported.
Proofs for the credentials are created in the linked data format, ldp_vc or ldp_vp, as described by the W3C data integrity specification [], using [] as the credential format and the JCS Ed25519 Signature 2020 [] signature type.
The [] specification is based on top of OAuth 2.0 [], which enables implementers to also build on top of OpenID Connect [] and the Self-issued OpenId Provider specification [].
state: OPTIONAL. State provided by the authorization client, that is passed through to the response.
A request MUST contain either a presentation_definition or a presentation_definition_uri. Those two ways to request credential presentations are mutually exclusive. The wallet MUST refuse any request violating this requirement.
Alternatively the request could contain the presentation_definition_uri parameter, containing a URL to a presentation definition object.
The following example shows a presentation definition object, requesting the presentation of a VerifiableId credential:
This is an example authorization request:
The response parameters depend on the response_type defined in the authorization request. Possible response parameters include:
state: Optional state parameter passed through from the authorization request.
If only vp_token is used as the response_type, the VP Token is provided in the authorization response.
If id_token is used as the response_type alongside vp_token, the VP Token is provided in the OpenID Connect authentication response along with the ID Token.
In all other cases, if vp_token is not used, but presentation_definition parameter is present, the VP Token is provided in the Token Response.
Any combination of vp_token with a response_type other than id_token is undefined.
The vp_token response parameter contains the verifiable presentation or array of verifiable presentations, matching the input descriptors of the presentation definition, specified in the authorization request.
This is an example response for the respones_type=vp_token request parameter, with the presentation_submission and vp_token response parameters:
An example vp_token, containing a presentation with a VerifiableId credential:
An example presentation_submission object:
This Login-with-IOTA profile of the [] specification supports only W3C Verifiable Credentials [].
Like described by [], verifiable presentations can be requested by adding the presentation_definition parameter to the authorization request. The presentation is returned in the vp_token response parameter.
Both, and flows are supported by this profile. For cross-device scenarios [] introduces a new response mode post, to support verifier initiated verification.
The parameters for a Login-with-IOTA authorization request, are a subset of the parameters defined by the [] specification:
response_type: REQUIRED. this parameter is defined in []. The possible values are determined by the response type registry established by []. This specification introduces the response type vp_token. This response type asks the Authorization Server (AS) to return only a VP Token in the Authorization Response.
presentation_definition: CONDITIONAL. A string containing a presentation_definition JSON object as defined in Section 4 of [].
presentation_definition_uri: CONDITIONAL. A string containing a URL pointing to a resource where a presentation_definition JSON object as defined in Section 4 of [] can be retrieved .
nonce: REQUIRED. This parameter follows the definition given in []. It is used to securely bind the verifiable presentation(s) provided by the AS to the particular transaction.
The presentation_definition parameter must contain a JSON representation of a Presentation Definition object, according to the DIF Presentation Exchange specification [].
vp_token: The verifiable presentation or array of presentations matching the presentation definition in the request. The required format in this profile is [] / []. The JSON data must be URL encoded. See also section 7.3 of [].
id_token: The ID token as defined by section 2 of the [] core specification.
presentation_submission: The presentation submission object, as defined in [], which links the input descriptors of the presentation definition in the request to the corresponding presentation(s) in the vp_token response.
Depending of the response_type given in the authorization request, the response should contain the following parameters, like described in section 6.1 of []:
The only supported format of the verifiable presentation in this specification is the [] / [] format. The JSON data can be either a single presentation object or an array of JSON objects and must be URL encoded.
The presentation submission object contains the correlations of the input descriptors, specified in the presentation definition of the authorization request, with the verifiable presentations in the VP token of the response. The format of the presentation submission objects is defined in section 6 of [].
For creating compliant error responses, please refer to section 6.3 of [].
For the same device flow, the verifier or relying party, links directly to the authorization endpoint of the wallet, passing the request parameters, as specified in the section.
The response_mode should be set to form_post. After getting the user consent, the wallet will generate the response parameters, as specified in the section, and performs a HTTP FORM POST action to the redirect_uri specified in the authorization request. The relying party can now verify the authorization response and redirect the user to the protected web page.
For the cross-device flow, the verifier or relying party initiates an internally cached authorization session and displays a QR code containing the authorization request URI with the request parameters, as specified in the section.
The response_mode should be set to post. The wallet scans the QR code and parses the authorization request. After getting the user consent, the wallet will generate the response parameters, as specified in the section, and posts the response to the redirect_uri specified in the authorization request, via the HTTP POST method. The relying party can now verify the authorization response and update the state of the internally cached authorization session. Depending on the concrete implementation (for example by polling for the session state), the relying party UI can now be refreshed and redirected to the protected page.
Terbu, O., Lodderstedt, T., Yasuda, K., Lemmon, A., Looker, T., "OpenID for Verifiable Presentations", September 2022,
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012,
Sporny, M., Longley, D., Chadwick, D., "Verifiable Credentials Data Model v1.1", March 2022,
IOTA Foundation, "IOTA Identity Framework Guide",
Millenaar, J., IOTA Foundation, "IOTA DID Method Specification",
Josefsson, S.; Liusvaara, I. (January 2017). Edwards-Curve Digital Signature Algorithm (EdDSA). IRTF. doi:10.17487/RFC8032. ISSN 2070-1721. RFC 8032.
Longley, D., Sporny, M., "Verifiable Credential Data Integrity 1.0",
Sporny, M., Longley, D., Kellog, G., Lanthaler, M., Champin, P., Lindström, N., "JSON-LD 1.1",
Cohen, G., Steele, O, Decentralized Identity Foundation, "JCS Ed25519 Signature 2020",
N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 1", November 8, 2014,
K. Yasuda, M. Jones, T. Lodderstedt, "Self-Issued OpenID Provider v2", September 2022,
Buchner, D., Zundel, B., Riedel, M., and K. H. Duffy, "Presentation Exchange 2.0.0", , .