Support pre-authorized code grant

[babisRoutis]

Currently, the issuer supports only the authorization code grant, given that by design it has been implemented as a resource server that is protected by any of the shelf authorization server.

To support pre-authorized code grant, under the above constraints, the following would be needed:

• Protect the issuer with two, possibly different, authorizations servers. One for authorization code grant and another for pre-authorized grant
• Issuer will advertise both authorizations servers, via credential issuer metadata, authorizations_servers claim
• Credential offers, would advertise the use of the first for grant authorization code & the second for pre-authorize code grant
• Credential endpoint would support access_token issued by either authorization server

Implementation
There are two possible ways to implement the above.

1. Create a minimal authorization server, exposing token endpoint and (authorization server) metadata and possibly token introspection endpoint
2. Embed the above into the credential issuer

[dariocast]

Will Pre-Authorized Code Flow be implemented in this Issuer? I studied the python version but I appreciate more the approach using an external authorization server. Under the above preliminary evaluation of needs, do you think will be viable a solution in which the issuer offer a pre-authorized form to insert data required by the credential subject without retrieving data from the authorization server?

[babisRoutis]

Will Pre-Authorized Code Flow be implemented in this Issuer? I studied the python version but I appreciate more the approach using an external authorization server. Under the above preliminary evaluation of needs, do you think will be viable a solution in which the issuer offer a pre-authorized form to insert data required by the credential subject without retrieving data from the authorization server?

Dear @dariocast

The implementation of the Pre-Authorized Code Flow is not currently in the immediate plans/priorities. Keep in mind that especially for HAIP this flow could be removed.

Having said this, my analysis above is focused on the OpenId4VCI aspects. To my understanding (spec-wise) it is a viable option, since the specification provides all that is needed (multiple authorization servers, specific authorization server per flow) for the Credential Issuer.

Implementation wise, I also think is more or less straightforward. Logically, two components are required:

• A minimal authorization server implementing pre-authorize code flow
• A component to keep the (pre)-authorizations

Minimal Authorization Server:

• Token endpoint just for pre-authorize code flow
• Metadata endpoint (advertising the AS)
• No user's needed (!!) : There is no need to have a user registry since there is no (user) authentication like in authorization code flow
• Token endpoint authorizes issuance (issues access_token) if it finds a matching pre-authorize code (and PIN) to the other component that keeps the pre-authorizations.

Pre-Authorization Components

• Basically that's a storage, that allows a higher-level application (responsible for performing the actual authorization) to store an anticipated pre-authorization.
• This storage will be looked up by the AS to make a decision for issuing an access_token or not.
• Finally, the Credential Issuer could also look up this storage (when wallet presents the access_token to retrieve the underlying issuing context).

Finally, a remark for the source from which the credential issuer retrieves the data needed to issue a credential. Usually the term used is "Authentic Source". The Authentic Source could be anything a database or another service as long as there is a way to associate an access_token to the data of the specific holder.

In the current implementation we use as "Authentic Source" for PID data kept to the user's profile in Keycloak. Yet this is not an absolute requirement. Merely a convenient implementation.