Update scope around issuance/create to be specific to credential manager selection

[timcappalli]

The goal of a create call in this spec is to assist with credential manager selection, and then essentially get out of the way (which is slightly different than get which expects a presentation response in the promise resolution).

We should be more explicit about this in the spec, maybe in the scope.

[mohamedamir]

I find the most confusing part is the return of DigitalCredential interface, while the members make sense protocol and data, the fact that a DigitalCredential is returned is confusing. Maybe we should create another interface e.g. DigitalCredentialIssuanceResponse that also inherits Credential? This is only slightly better though because if the Credential inheritance.

[marcoscaceres]

Maybe the semantics of .create() are not right then in Cred Man?... should Cred Man or our API maybe sprout a new method? .issue() or something?

I guess it really depends on how long issuance takes normally and if no one is realistically expecting a credential back quickly... as well as the UI.

but also, if .create() or issue() resolves quickly, what does it mean for the web application? And does the developer need to wait for some out-of-band signal that the credential has been issued? (even if takes a few minutes) That seems not great.