Open TakahikoKawasaki opened 5 months ago
@TakahikoKawasaki I think that point (3) is not correct.
To my understanding, credential_identifiers
can be used to
An example of the later case is to, assuming a credential "Birth Certificate", be able to request (using credential_identifiers
) which is the subject of the credential (my son's, mine etc). My point is that credential_identifiers
is not always a configurable value and in some cases needs to be evaluated dynamically.
BTW, the current draft imposes the following restriction.
Note: Credential Instance identifier(s) cannot be used when scope parameter is used in the Authorization Request to request issuance of a Credential.
Technically speaking, the credential_identifers mechanism cannot coexist with the issuer_state parameter, either.
However, the reason why this restriction is needed is that credential_identifiers is placed INSIDE the authorization_details object. Placing the information OUTSIDE, like the following conceptual example, would enable the credential_identifiers mechanism to coexist with scope and issuer_state.
yes, that's why I also filed #132. I support a top-level identifier parameter.
I do not support the top level credential identifier for credentials requested with authorization details. Reason: every credential identifier represents a concrete credential dataset authorized by the respective authorization detail. This link would not exist any longer if the identifier is moved out of the authorization detail.
let me clarify my comment. I see the need for a top-level identifier parameter that can be used with scopes
(and not RAR) but I think that is better achieved by enabling credential_configuration_id
to be used in the credential request, as opposed to making top-level existing credential_identifiers
parameter that is meant to be used with RAR (and not scopes).
I think there might be several misunderstandings in the original issue.
According to the explanation, the identifiers in the credential_identifiers array do NOT represent requested credentials but do represent just credential variants with a pre-configured set of claims. ... To simplify the corresponding credential request, a token response should contain an identifier that represents the exact set of the requested claims.
This is not prohibited. Issuer can return one entry in authorizaiton_details.credential_identifier
array that represents exactly what was requested and can be used to simplify the credential request. This should probably be clarified in the definition of authorizaiton_details.credential_identifier
in the Token Request.
A token response is not a suitable place to put information about credential variants with a pre-configured claim set, like CivilEngineeringDegree-2023 and ElectricalEngineeringDegree-2023. Such static information should be placed in the credential issuer metadata. The following is a conceptual example.
This mechanism was introduced to issue not pre-configured/not static claim sets, that are represented by the same credential_configuration_id in the issuer metadata.
However, the reason why this restriction is needed is that credential_identifiers is placed INSIDE the authorization_details object. Placing the information OUTSIDE, like the following conceptual example, would enable the credential_identifiers mechanism to coexist with scope and issuer_state.
If one of the motivations for this proposal is to enable the credential_identifiers mechanism to coexist with scope and issuer_state.
, would really appreciate feedbak on the proposal in the first paragraph of this comment and this issue #132. cc @TakahikoKawasaki
should be resolved by the PRs addressing #294 (including #346)
The OID4VCI draft states
authorization_details[*]
in a token response may contain acredential_identifiers
array. The following is an example from the spec.According to the explanation, the identifiers in the
credential_identifiers
array do NOT represent requested credentials but do represent just credential variants with a pre-configured set of claims.Therefore, when a RAR object like below comes, which is an example listed in "E.2.3. Authorization Details", the mechanism of
credential_identifiers
does not contribute to simlifying a credential request.To simplify the corresponding credential request, a token response should contain an identifier that represents the exact set of the requested claims. The following is a conceptual token response to achieve the goal - the
credential_identifier
property is added in the RAR object.BTW, the current draft imposes the following restriction.
Technically speaking, the
credential_identifers
mechanism cannot coexist with theissuer_state
parameter, either.However, the reason why this restriction is needed is that
credential_identifiers
is placed INSIDE theauthorization_details
object. Placing the information OUTSIDE, like the following conceptual example, would enable thecredential_identifiers
mechanism to coexist withscope
andissuer_state
.A token response is not a suitable place to put information about credential variants with a pre-configured claim set, like
CivilEngineeringDegree-2023
andElectricalEngineeringDegree-2023
. Such static information should be placed in the credential issuer metadata. The following is a conceptual example.The summary is as follows.
credential_identifiers
fromauthorization_details[*]
in a token response.credential_identifiers
(or something equivalent) as a top-level property in a token response.credential_identifiers
from "identifiers of pre-configured claim sets" to "identifiers of requested claim sets".