User friendly names and registration of providers

Issue #104 new
Tom Jones created an issue

At several places in OpenID implementations it has become clear that when provider registration occurs dynamically the counter-party is not left with any name of the other party to display to the user. Also in this case, and in the case of UK Open Banking, a requirement exists to know whether the counter-party is a member of the framework that is permitted to interact and share user data. I believe that a new document is in order to address both requirements. Since it is needed for fapi transactions I would suggest it be created in fapi. I have create a document for another body that could be used as a base set of requirements for such a doc. https://wiki.idesg.org/wiki/index.php?title=Trust_Framework_Membership_Validation#Introduction

Comments (7)

  1. Tom Jones reporter

    Yeah, I looked at that and included a reference to it in my write up. It addresses neither of the issues in this proposal and seems to Target only client code on the phone. It would be of limited use in a commercial site that could be updating the software guid every day. Perhaps I should specify that the target is large systems running on the web.

  2. Tom Jones reporter

    For the reason mentioned above, the software in a relying party (client) is far too volatile and can be changing during the day and if a/b testing is running there may even be two or more instances running at the same time. They will have different guids.

  3. Tom Jones reporter

    I reviewed Federation 1.0 - draft 03. This is mostly populated with OpenID Connect fields. It also mandates the use of a Certificate Transparency log that does not appear to be widely deployed. The FO, or Trust Anchor, has a requirement to be technology agnostic. Even though the data supplied by the FOmust be in a specific format, most of the metadata described in the federation document is specific to Open ID technology used between the OP and RP. That is not permitted by the specific FO that drove me to seek this solution.

    So the question is whether the Open ID federation is willing to support an FO that is required by its own rules to be technology agnostic.

  4. Log in to comment