-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Policy backend API spec #2607
Policy backend API spec #2607
Changes from 1 commit
5279dfb
b829742
b878710
6008f49
e4cb0d8
360a7e4
124df4f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,133 @@ | ||
openapi: 3.1.0 | ||
info: | ||
title: Policy backend API specification | ||
version: 0.1.0 | ||
servers: | ||
- url: "http://localhost:1323" | ||
paths: | ||
/{did}/presentation_definition: | ||
parameters: | ||
- name: did | ||
in: path | ||
description: URLEncoded DID. | ||
required: true | ||
example: did:web:example.com:1 | ||
schema: | ||
type: string | ||
- name: scope | ||
in: query | ||
description: | | ||
This is the scope used in the OpenID4VP authorization request. | ||
It is a space separated list of scopes. | ||
required: true | ||
schema: | ||
type: string | ||
get: | ||
summary: Returns a presentation definition for the given DID and scope. | ||
description: | | ||
The DID is used for tenant selection. Not all tenants will probably support the same scopes. | ||
The scope is used as selection criteria for the presentation definition. | ||
It could be the case that the presentation definition is not found. | ||
In that case the response will be 201 with an empty body. | ||
operationId: "presentationDefinition" | ||
tags: | ||
- policy | ||
responses: | ||
"200": | ||
description: | | ||
DID has been found and the scope is supported. | ||
If the scope is supported but no presentation definition is required, the response will be 200 with a presentation definition without any input descriptors. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what would the use case for this be? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. public service, like a directory service |
||
content: | ||
application/json: | ||
schema: | ||
$ref: '#/components/schemas/PresentationDefinition' | ||
"201": | ||
description: The DID is known but the presented scope is not supported. | ||
"404": | ||
description: DID is not known to the policy backend. | ||
/{did}/authorize: | ||
parameters: | ||
- name: did | ||
in: path | ||
description: URLEncoded DID. The DID is used for tenant selection. | ||
required: true | ||
example: did:web:example.com:1 | ||
schema: | ||
type: string | ||
post: | ||
summary: Authorize a resource request. | ||
description: | | ||
When an access token is used to request a resource, the resource server needs to know if the access token grants access to the requested resource. | ||
The resource server will send a request to the policy backend to check if the access token grants access to the requested resource. | ||
|
||
woutslakhorst marked this conversation as resolved.
Show resolved
Hide resolved
|
||
operationId: "authorize" | ||
tags: | ||
- policy | ||
requestBody: | ||
description: Required params for policy backend to make an informed decision. | ||
required: true | ||
content: | ||
application/json: | ||
schema: | ||
$ref: '#/components/schemas/AuthorizeRequest' | ||
responses: | ||
"200": | ||
description: A response that indicates if the access token grants access to the requested resource. | ||
content: | ||
application/json: | ||
schema: | ||
$ref: '#/components/schemas/AuthorizeResponse' | ||
"404": | ||
description: DID is not known to the policy backend. | ||
components: | ||
schemas: | ||
AuthorizeRequest: | ||
description: | | ||
The request contains all params involved with the request. | ||
It might be the case that the caller mapped credential fields to additional params. | ||
type: object | ||
required: | ||
- client_id | ||
- scope | ||
- request_url | ||
- request_method | ||
- presentation_submission | ||
- vps | ||
Comment on lines
+86
to
+88
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These are optional? Most backends probably can't handle PEX/VC/VP There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The first versions might just have to, we'll have to experiment a bit to see what's useful. |
||
properties: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. missing the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Then the entire id to value mapping would have to be standardised. I think it's too early for a decision on that. With the VPs included, a backend can make a decision. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was under the impression that we would introduce this mapping so other parties do not have to deal with PEX/VC/VP and just check the string value they need extracted from the VC/VP. (makes it easier to start) Do you still want to add this? If not (or undecided) we should probably remove the map from the introspection endpoint too for now There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That'll be an incremental change. We can then also process feedback in the same change. |
||
client_id: | ||
description: The client ID of the client that requested the resource (DID). | ||
type: string | ||
scope: | ||
description: The scope used in the authorization request. | ||
type: string | ||
request_url: | ||
description: The URL of the resource request. | ||
type: string | ||
request_method: | ||
description: The method of the resource request. | ||
type: string | ||
presentation_submission: | ||
description: The presentation submission that was used to request the access token. | ||
type: object | ||
vps: | ||
description: | | ||
The verifiable presentations that were used to request the access token. | ||
The verifiable presentations could be in JWT format or in JSON format. | ||
type: array | ||
AuthorizeResponse: | ||
description: | | ||
The response indicates if the access token grants access to the requested resource. | ||
If the access token grants access, the response will be 200 with a boolean value set to true. | ||
If the access token does not grant access, the response will be 200 with a boolean value set to false. | ||
type: object | ||
required: | ||
- authorized | ||
properties: | ||
authorized: | ||
description: Indicates if the access token grants access to the requested resource. | ||
type: boolean | ||
PresentationDefinition: | ||
description: | | ||
A presentation definition is a JSON object that describes the desired verifiable credentials and presentation formats. | ||
Specified at https://identity.foundation/presentation-exchange/spec/v2.0.0/ | ||
A JSON schema is available at https://identity.foundation/presentation-exchange/#json-schema |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
read the docs
Not sure if it matters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no