This should become an extension of the OAuth 2.0 Authorization Server, and the current draft should include the authorization endpoint or reference a new draft defining this specific Authorization Server in the form of a wallet provider.
We suppose that the wallet provider can only issues attestations of complaince to the wallet instances belonging to it.
In the brand new world that is coming with the Wallet ecosystems, there might be more complex scenario where a wallet instance attestation might be issued through a neutral attestation service.
This opportunity may arise from real-world market dynamics, extending beyond the current and temporary limitations we might perceive.
This opens several challenges, since it requires a clear guidance about the interoperability. There might be wallet providers using propertary flows with their wallet instances, at the same time there might be other situations where interoperability (and security) requires a common standard.
To simplify, I would address this point by focusing on the needs of our implementers who rely on technical specifications to implement solutions comfortably. The advantage of using OAuth 2.0 or the OpenID Frameworks is that they significantly reduce implementation costs. Our specifications should aim to meet these needs and address these questions.
We could continue this work in a dedicated draft concerning wallet authorization servers. The scope of this draft would be how to authorize a wallet performing its operations in accordance with a framework, providing proof of its compliance (token, thus wallet attestation). This could introduce several architectural points of interest for technical implementations and also for the market. This would remark the need to reduce the content in the openid federation wallet architecture by referencing other openid4vc specifications.
This should become an extension of the OAuth 2.0 Authorization Server, and the current draft should include the authorization endpoint or reference a new draft defining this specific Authorization Server in the form of a wallet provider.
We suppose that the wallet provider can only issues attestations of complaince to the wallet instances belonging to it. In the brand new world that is coming with the Wallet ecosystems, there might be more complex scenario where a wallet instance attestation might be issued through a neutral attestation service. This opportunity may arise from real-world market dynamics, extending beyond the current and temporary limitations we might perceive.
This opens several challenges, since it requires a clear guidance about the interoperability. There might be wallet providers using propertary flows with their wallet instances, at the same time there might be other situations where interoperability (and security) requires a common standard.
To simplify, I would address this point by focusing on the needs of our implementers who rely on technical specifications to implement solutions comfortably. The advantage of using OAuth 2.0 or the OpenID Frameworks is that they significantly reduce implementation costs. Our specifications should aim to meet these needs and address these questions.
We could continue this work in a dedicated draft concerning wallet authorization servers. The scope of this draft would be how to authorize a wallet performing its operations in accordance with a framework, providing proof of its compliance (token, thus wallet attestation). This could introduce several architectural points of interest for technical implementations and also for the market. This would remark the need to reduce the content in the openid federation wallet architecture by referencing other openid4vc specifications.