-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: openid credential issuer discovery example #100
Conversation
docs/en/pid-eaa-issuance.rst
Outdated
@@ -37,7 +37,7 @@ The :numref:`fig_High-Level-Flow-ITWallet-PID-Issuance` shows a general architec | |||
Below a detailed description for each step represented in the previous picture: | |||
|
|||
0. **Wallet Instance Setup**: the first time the Wallet Instance is started a preliminary setup phase MUST be carried out. It consists of the release of a verifiable proof issued by the Attestation Service provided by the Wallet Provider that asserts the genuineness, the authenticity and the compliance with a trust framework of the Wallet Instance. The verifiable proof binds a public key corresponding to a local private key generated by the Wallet Instance. | |||
1. **Obtaining the trusted PID Provider**: the Wallet Instance queries the Trust Anchor to fetch the trusted PID Provider. | |||
1. **Obtaining the trusted PID Provider**: the Wallet Instance discovers the trusted PID Provider, eg: `https://trust-anchor.eudi.wallet.developers.italia.it/list?entity_type=openid_credential_issuer` and then inspects the metadata looking to the availability of the PID credential. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Following @rohe suggestions
Obtaining the trusted PID Provider has these steps:
-
Use the federation list interface with a query like what you specify:
https://trust-anchor.eudi.wallet.developers.italia.it/list?entity_type=openid_credential_issuer
-
Then for each of the entity_ids returned collect their metadata and look for what ? credentials_supported:credential_definition:type == ??
@fmarino-ipzs I think that we should specify in the second point the domestic PID namespace used for discovering the credential availability upon a specific issuer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the PID Provider Metadata we have credential_supported:credential_definition:type=PersonIdentificationData
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway, I think that it is better to add a new section describing the discovery phase, with some non-normative examples, for the sake of readability. What do you think? This is a high-level view I wouldn't go into details here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I agree
Resolves #96