Closed OIDF-automation closed 2 months ago
OIDF-automation
commented
2 years ago Would a greater simplification be to remove the concept of an acceptance token entirely and just use the issued access token instead?
OIDF-automation
commented
2 years ago Can you please describe what the complexity is behind the acceptance token?
The acceptance token is the identifier of an active issuance process. It saves the client to calculate and send the credential issuance request multiple times. The access token cannot compensate for it since it can (at least spec wize) be used for multiple transactions (even in parallel). So removing the acceptance token would make the endpoint simpler but also means the client would need to calculate the PoP multiple times and the issuer would loose the ability to identify a running transaction.
OIDF-automation
commented
2 years ago @Kristina. Why would the wallet want deferred issuance. Can you explain please? Surely we can assume that the user/wallet will not start the issuance process if it knows it cannot complete it?
Assuming it is the issuer that thinks it requires deferred issuance, then a better simpler model is as follows. If the issuer knows it cannot issue a credential immediately when the wallet asks for it, then the model should be that the issuer does not allow the wallet to start the credential issuance process. Rather the user should interact with the issuer by out of band means to start the application process, fulfil all the issuer’s requirements, and then wait to be notified that the credential is ready. The user can then use their wallet to interact with the issuer and get immediate issuance of the credential. We can then remove any concept of a deferred issuance from the specification.
OIDF-automation
commented
2 years ago Getting rid of the deferred issuance sounds appealing to me because simpler is almost always better. I also think issuer and user can manage that in situations where all the preparation is out of band from the perspective of the protocol (pre authz code).
I’m not sure regarding the inline issuance. We have a use case for this at https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-deferred-credential-issuanc.
Let’s assume the user starts the process in the wallet and wants to obtain a credential from an issuer it picks for that purpose. Protocol wize this means the wallet starts an authorization process with the issuer. The issuer now might authenticate or identify onboard the user and suddenly realize that it cannot immediately issue a credential. The way I understand your proposal, it would suspend the process and send the user back to the wallet with an error response.
I would hope the user could resume the process where the issuer suspended it. But without any indicator exchanged between issuer and wallet, how would envision this to work?
Also, it might be the case that the issuer was able to gather all the data required for issuance from the user. So it would be cumbersome to send the user through the authorization flow again just to get the access token to get the credential when it is ready. How would you solve that?
OIDF-automation
commented
2 years ago @ Torsten. This use case is exactly the one I was thinking of. Having had to just go through this process myself before I could house a Ukrainian refugee family, I started the process on the DBS (Disclosing and Barring Service - the UK name for police record checking) web site and had to upload several documents. I then had to wait over a week for an interview (online) whose purpose was essentially to verify that the documents I had uploaded were genuine, and another week or so before my certificate was ready. I was then notified that my certificate was ready, and it arrived in the post about a week later.
I did not start in the wallet, and I don’t think I ever would until the entire process is automated. I could imagine the following scenario once VCs are ubiquitous. I go to the DBS web site (the RP) on my device’s browser, and it sends its presentation request to my wallet containing the list of certificates it wants. My wallet assembles then into a VP, returns them to my browser and from there to the web site. I could then be redirected to the certificate issuing site (if no human checking is required) and have my certificate issued immediately. Alternatively if a human is involved in the loop, the RP would display a thankyou page and say I will be notified when my certificate is ready. In either case delayed issuing is not required.
OIDF-automation
commented
2 years ago I think there is value in the wallet initiated process, it can guide to user through the process (for example to find an appropriate issuer) and the wallet can act as user agent to keep track of the progress. And since one doesn’t necessarily know whether the process is short or long in the beginning I also see a need for deferred issuance.
And to your example: how can the wallet assemble a VP without credentials? Why should credential issuance be possible immediately in this case?
OIDF-automation
commented
2 years ago @Torsten. Because to apply for a DBS certificate I have to provide my passport, utility bill and bank statement. So the VP would ask for these credentials, whilst the issuing process would issue the DBS certificate once the other credentials are validated.
I really cannot see why the wallet would initiate this process, unless you want it to become a browser as well (which is hardly Keep It Simple)
OIDF-automation
commented
2 years ago So the VP would ask for these credentials, whilst the issuing process would issue the DBS certificate once the other credentials are validated.
I would say this is not the typical example of deferred issuance. If the prerequisites of the DBS issuance are not fulfilled (e.g. you don’t have a passport credential), the issuance process would stop.
Deferred issuance means that the pre-requisites are fulfilled but the issuer is not able to directly issue, might be a technical issue, might be caused by the fact something needs to be done in the background before issuance.
OIDF-automation
commented
2 years ago @Torsten. I think your description of deferred issuance “the issuer is not able to directly issue, might be a technical issue, might be caused by the fact something needs to be done in the background before issuance” supports my assertion that the issuer should not start the issuance process until it knows it can complete it. Instead if should have a pre-issuance process that does not involve the wallet (or if it wants some VCs from the wallet, then this is the standard RP-Verification interaction which we already have defined).
OIDF-automation
commented
2 years ago As already stated above, deferred issuance is relevant for wallet initiated issuance.
And in the use case we have in the spec the issuer doesn’t know whether it can immediately issue the credential up until it authenticated the user. If it detects it cannot issue directly, it switches to deferred issuance. This ensures the process can be completed in a user friendly manner.
I don’t see how pre authorized code could help.
OIDF-automation
commented
2 years ago I think we have identified the nub of the problem. When is it relevant for the wallet to initiate issuance on its own without any prior communication with the issuer. I submit that it is not. Can you please explain why you think it is and how it might work in practice. Thanks.
OIDF-automation
commented
2 years ago How this technically works is described in the spec in length: https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html#name-authorized-code-flow
OIDF-automation
commented
2 years ago So the first step is for the wallet to obtain the issuer’s metadata (which sort of counts as communication with the Issuer in my book). Perhaps we could alleviate the need for delayed issuing by having something in the metadata telling the wallet that if it wants a credential of type X (which cannot be issued on demand) then the user should first visit URL Y, which will allow the credential application process to be completed prior to issuing the credential (the URL Y will act as an RP, requesting specific info from the user, as either credentials from the wallet or other information that is not in the wallet). After the application is approved the user will be notified to start the issuing process.
Maybe also the access_token from the application process can also be used as the access_token for the issuing process, which will reduce the number of protocol message exchanges?
OIDF-automation
commented
2 years ago Perhaps we could alleviate the need for delayed issuing by having something in the metadata telling the wallet that if it wants a credential of type X (which cannot be issued on demand) then the user should first visit URL Y, which will allow the credential application process to be completed prior to issuing the credential (the URL Y will act as an RP, requesting specific info from the user, as either credentials from the wallet or other information that is not in the wallet).
Such metadata could inform the wallet that the issuer potentially/always requires a certain credential as pre-requisite for issuing a credential. It does not cover scenarios where the issuer determines in the course of the process what is needed based on the actual user data.
And again: the deferred issuance is not related to the fact there is a missing pre-requisite for credential issuance authorization. It is related to the fact that there might be processing after the authorization by the user and before the technical issuance that require the wallet to wait.
Maybe also the access_token from the application process can also be used as the access_token for the issuing process, which will reduce the number of protocol message exchanges?
That’s what the access token is used for. https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html#name-credential-request
OIDF-automation
commented
2 years ago “It is related to the fact that there might be processing after the authorization by the user and before the technical issuance that require the wallet to wait.” Can you give an example of this please? And could the processing lead to rejection of the user’s request for a credential? Or is it always bound to proceed?
OIDF-automation
commented
2 years ago Can you please describe what the complexity is behind the acceptance token?
Apologies you are correct, the acceptance token provides further functionality above the access token, please dis-regard my comment I was thinking about it in the wrong context.
OIDF-automation
commented
2 years ago Can you give an example of this please?
I was thinking about manual background checks or just technical reasons (e.g. the systems are not directly connected and some batch processing is involved, which delays the issuance). I think the first example could lead to a rejection.
OIDF-automation
commented
2 years ago I agree with your use case examples. When manual background checks are required then I suggest we model this as an application process, where the issuer is an RP, followed by a notification (email or SMS) that all checks are complete and the application has been accepted (or rejected with reason), followed by immediate issuing (so no delayed issuing is needed). When batch processing or similar is involved so that issuing cannot be instantaneous, couldn’t we say that the issuer replies with a 202 (Accepted) and a retry-later parameter telling the wallet when to try again to pick up the credential. In this way we can remove the deferred credential endpoint.
OIDF-automation
commented
2 years ago When manual background checks are required then I suggest we model this as an application process, where the issuer is an RP, followed by a notification (email or SMS) that all checks are complete and the application has been accepted (or rejected with reason), followed by immediate issuing (so no delayed issuing is needed).
It feels we are turning cycles here. If the wallet starts the process, it does not necessarily know whether the issuance will be deferred or not.
couldn’t we say that the issuer replies with a 202 (Accepted) and a retry-later parameter telling the wallet when to try again to pick up the credential.
That’s basically what deferred issuance does.
OIDF-automation
commented
2 years ago So we can remove the deferred credential endpoint and allow the wallet to send the access token to issuing endpoint again after the retry period has expired.
OIDF-automation
commented
2 years ago That’s the idea.
OIDF-automation
commented
2 years ago But it also means that deferred issuance cannot fail as the issuer is only waiting for a batch process to complete i.e. the issuance process is already a success when 202 (accepted) is returned (or the acceptance token). (Apart from a 500 server error which can always happen).
When the issuer is using humans to process the request (which can fail) then I submit that this should still be modelled as an application followed by an issuing after the application is successful. I do not think that telling the user everything is OK and the issuing is accepted but delayed, and then telling the user that the issuing has failed because his application has been rejected is an appropriate user experience.
OIDF-automation
commented
2 years ago create PR #247
OIDF-automation
commented
1 year ago Deferred Endpoint is very underspecified (Issues #1604, #1653, etc.), has security implication (Issue #1808). I seriously think we should merge this functionality into a Credential Endpoint.
OIDF-automation
commented
1 year ago Can you please describe how the issues raised are fixed by merging the endpoint into credential issuance? I think whether we treat it as part of one or the other endpoint, deferred issuance is different from instant issuance. It requires a different parameter set. So we would end up with a selector (grant type alike) request type selector. No reduction in complexity but reduction in deployment flexibility.
Sakurann
commented
2 months ago closing it as someone who opened it as I think there is no implementation experience pointing towards merging.
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1553
Original Reporter: KristinaYasuda
Simplify deferred issuance by using credential endpoint to do a deferred issuance instead of a separate endpoint called deferred credential endpoint. for example, right now, two separate endpoints need to manage status of
acceptance_token.When the Wallet wants deferred issuance, it will send acceptance token to the credential endpoint using the same access token it initially used to obtain acceptance_token.