> For the complete documentation index, see [llms.txt](https://dev.ishare.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dev.ishare.eu/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/authorization-endpoint-openid4vp.md).

# Authorization Endpoint (OpenID4VP)

{% hint style="info" %}
Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments.
{% endhint %}

The `GET` or `POST` request to the authorisation endpoint initiates a verifiable presentation request. This endpoint is part of the OpenID for Verifiable Presentations (OpenID4VP) protocol and follows OAuth 2.0 authorisation flow patterns.

{% hint style="info" %}
The authorisation endpoint for OpenID4VP is an **OPTIONAL** endpoint and is part of the iSHARE Framework's Verifiable Credentials support in line with **OpenID for Verifiable Presentations (OpenID4VP)**.
{% endhint %}

### Endpoint

```
GET /authorize
POST /authorize
```

The URL for this endpoint is provided in the Verifier Metadata (see [Verifier Metadata](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/verifier-metadata-openid4vp.md)). This endpoint may be the same as the standard iSHARE authorisation endpoint, but supports additional parameters for verifiable presentation requests.

### Request model

#### Parameters

The request parameters follow the OAuth 2.0 authorisation request format with OpenID4VP-specific additions:

* `response_type`\
  **String**. <mark style="color:red;">(Required)</mark>\
  OAuth 2.0 response type. For OpenID4VP, MUST include `vp_token` (e.g., `vp_token` or `code vp_token`).
* `client_id`\
  **String**. <mark style="color:red;">(Required)</mark>\
  The client identifier. Within iSHARE, this MUST contain a valid [Party Identifier](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role/party-identification) when applicable.
* `redirect_uri`\
  **String**. <mark style="color:red;">(Required)</mark>\
  The redirect URI where the response will be sent.
* `scope`\
  **String**.\
  OAuth 2.0 scope parameter. May include credential types or presentation scopes.
* `presentation_definition`\
  **Object**.\
  A [Presentation Definition](https://identity.foundation/presentation-exchange/spec/v2.1.1/#presentation-definition) object specifying the required credentials and constraints.
* `presentation_definition_uri`\
  **String**.\
  A URI pointing to a Presentation Definition document.
* `nonce`\
  **String**.\
  A nonce to prevent replay attacks.
* `state`\
  **String**.\
  OAuth 2.0 state parameter for maintaining state between request and callback.

### Example request

```
GET /authorize?response_type=vp_token&client_id=did:ishare:EU.NL.NTRLNL-10000001&redirect_uri=https://wallet.example.com/cb&scope=openid&presentation_definition_uri=https://verifier.ishare.eu/presentation-definitions/participant-credential&nonce=abc123&state=xyz789
Host: verifier.ishare.eu
```

### Response model

The response follows OAuth 2.0 authorization response format:

* `vp_token`\
  **String**.\
  A verifiable presentation token (when `response_type` includes `vp_token`).
* `code`\
  **String**.\
  An authorization code (when `response_type` includes `code`).
* `state`\
  **String**.\
  The state parameter value from the request.
* `presentation_submission`\
  **Object**.\
  A [Presentation Submission](https://identity.foundation/presentation-exchange/spec/v2.1.1/#presentation-submission) object when using presentation definitions.

### Example response

The response is typically a redirect to the `redirect_uri` with parameters:

```
https://wallet.example.com/cb?vp_token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...&state=xyz789
```

### iSHARE-Specific Requirements

Within iSHARE, the following requirements apply:

* Clients (holder applications) MUST NOT be pre-registered. A look-up in the Participant Registry is sufficient.
* The `client_id` MUST contain a valid Party Identifier when applicable.
* The verifier MUST validate the requesting party's authorization to request verifiable presentations.
* The authorization endpoint may be the same as the standard iSHARE authorization endpoint used for OpenID Connect flows, but MUST support the additional OpenID4VP parameters.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://dev.ishare.eu/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/authorization-endpoint-openid4vp.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.