OpenID4VP
OpenID4VP copied to clipboard
openid
Do new entity types required for OID4VP/SIOPv2 to use Entity Statements defined in OpenID Federation?
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1781
Original Reporter: KristinaYasuda
Brought up during Connect call. I am honestly not sure. MikeJ said it is up to the editors of OID4VP. guidelines how to think about the need would be appreciated.
Imported from AB/Connect bitbucket - Original Commenter: peppelinux
I can confirm what Mike said, as stated here
https://openid.net/specs/openid-connect-federation-1_0.html#section-4
Imported from AB/Connect bitbucket - Original Commenter: dayday101
Im really not sure what to think ,but the issue needs to be addressed
Imported from AB/Connect bitbucket - Original Commenter: peppelinux
OIDC Federation:
1. allows new metadata types to be defined to support use cases outside OpenID Connect federations.
2. The metadata type identifier will uniquely identify which metadata specification to utilize.
3. The metadata document MUST be a JSON object. Beyond that, there is no restriction.
said that, I can imagine this in an Entity Configuration:
"metadata" : {
"openid_self_issued_provider": {},
"openid_credential_issuer": {},
}
even if the openid_credential_issuer may be simply configured as oauth_authorization_server
this should be valid also for OpenID4VP, it could be defined as oauth_authorization_server
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda
so guess the recommendation is to define in the OpenID4VC specs if needed?
PS openid_credential_issuer should not use oauth_authorization_server because it is a resource server, and has a separate metadata file from the AS per the VCI spec.
Imported from AB/Connect bitbucket - Original Commenter: peppelinux
Good, I wrote it then i delete and that was good, as optionally mixed with oauth protected resource if both services are on the same entity. All returns, thank you for the hint
Imported from AB/Connect bitbucket - Original Commenter: peppelinux
Regarding the OIDC Federation Entity Type oauth_resource , [here](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-5.1.2) I read
If the Credential Issuer metadata contains an authorization_server property, it is RECOMMENDED to use a resource parameter [RFC8707]
whose value is the Credential Issuer's identifier value to allow the AS to differentiate credential issuers.
@Kristina what about including an example or a guidance in the Metadata section [here](https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html#section-10) to clarify the role of OAuth protected resource according to https://datatracker.ietf.org/doc/html/draft-jones-oauth-resource-metadata?
please correct me if something is wrong
Imported from AB/Connect bitbucket - Original Commenter: mbj
It’s absolutely appropriate for specs other than the Federation spec to define any new entity types that they need.
As discussed on the 13-Jan-23 Federation Editors' call, we believe the question asked in the issue has been answered. We plan to close this on that basis in a week unless a reason to keep it open is raised.
Imported from AB/Connect bitbucket - Original Commenter: mbj
A week has passed with no further comments. Closing during the 20-Jan-23 Federation Editors' call, as proposed last week.
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda
I think we were discussing if we need a text in openid4vc specs and I don't have an answer yet. it should not be closed yet.
Imported from AB/Connect bitbucket - Original Commenter: peppelinux
I’ve learned that Verifiers/RP uses "client_metadata" as defined in OpenID4VP. It's so wide ... considering that it is a just VC verfifier, but that would be another story.
OpenID4VCI defines openid-credential-issuer and it makes sense.
Then we should have also wallet_provider ?
Imported from AB/Connect bitbucket - Original Commenter: peppelinux
The new entity types proposed, as a result of the experience of the implementers, are listed below:
- wallet_provider
- wallet_relying_party
while the wallet instance metadata should be carried in the wallet instance attestation.
@peppelinux is there additional implementation experience on this? is this still needed?
From our implementation experiences in openid4vci, we've gained valuable insights and have been able to distinguish between the metadata oauth_authorization_server and openid_credential_issuer, underscoring their distinct roles.
The focus of this discussion is on defining metadata types that align with the specific capabilities of each entity within the protocol.
For example, within the wallet ecosystem, we've identified the need for specific metadata claims for the relying party, indicated by the HTTP request parameter client_metadata. In this process, we're also introducing a new entity, the wallet relying party. This distinction has highlighted the necessity for defining unique metadata types tailored for the wallet ecosystem, such as:
wallet_relying_party
wallet_provider
These distinctions helps us in accurately defining the roles and capabilities of entities within the wallet ecosystem.
It appears evident that OpenID4VP should remain a protocol-specific application, distinct from trust framework-specific implementations, such as those concerning OpenID Federation metadata types.
Given this perspective, it would be better to define such properties outside of this specification to maintain clarity and focus within the protocol's scope. This approach ensures that OpenID4VP can continue to evolve effectively without the complexities introduced by overlapping with trust framework specifics.
Therefore I'm prone to close this issue.
Is the situation that to use federation with OID4VP & VCI that new entity types like wallet_relying_party and wallet_provider do need to be defined? If so we still need to decide where those will be defined?
openid federation already seems to be defining a lot of entity types. to me, it sounds like EUDIW specific entity types should be defined there.