What's an appropriate expiry time for the STS in the issuance case?

[arnoweiss]

Between step 6 and 7, there's a risk that either

• a token expires before a human-centered business process can decide for/against issuance
• a token lives longer than a technical process requires

[nikschul]

I'd argue that for a fully asynchronous operation there should be an option to refresh the token. However, this would require the Issuer to reach back out to the Client Entity, of which we probably cannot expect to be reachable all the time.

In the end, I think we should either decide for a asynchronous option here and then also provide the option to refresh the token or make the entire issuance process non-async.

[arnoweiss]

It's not up to debate if it's asynchronous - rather if the spec considers the case of manual human intervention to be a good practice. There's two ways to use DCP Issuance:

Triggered by Issuer:

• Issuer sends CredentialOfferMessage without prior interaction.
• Holder sends CredentialRequestMessage with STS-token from Holder.
• Issuer receives it, correlates the incoming message with a list of sent CredentialOfferMessage. If successful, responds with a CredentialMessage.

This is a fully automatable process, thus the time-to-live (ttl) for the token can be fairly short.

Triggered by Holder:

• Holder sends CredentialRequestMessage with STS-token without any prior interaction.
• Issuer responds
  • EITHER automatically by fetching a consumer's presentation and inspecting it against internal policies
  • OR after manual inspection of the request (and perhaps a subsequent presentation)

Only the second scenario requires a fairly long ttl. We should point that in the best practices out in case someone tries to implement it in that manner. The usecases I'm aware of are all triggered by the issuer so a refresh isn't a requirement right now.