Skip to content
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

Merged
merged 7 commits into from
Nov 23, 2023
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
133 changes: 133 additions & 0 deletions docs/_static/policy/v1.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,133 @@
openapi: 3.1.0
Copy link
Member

@gerardsn gerardsn Nov 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

read the docs

We use version 3.0.y of the OAS.

Not sure if it matters

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what would the use case for this be?

Copy link
Member Author

Choose a reason for hiding this comment

The 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are optional? Most backends probably can't handle PEX/VC/VP

Copy link
Member Author

Choose a reason for hiding this comment

The 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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing the input_desciptor_constraint_id_map from the introspection endpoint? Could probably use a simpler name here.

Copy link
Member Author

Choose a reason for hiding this comment

The 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.

Copy link
Member

Choose a reason for hiding this comment

The 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

Copy link
Member Author

Choose a reason for hiding this comment

The 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
Loading