User friendly names and registration of providers

[Tom Jones]

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

[Torsten Lodderstedt]

The WG may want to take a look onto http://openid.net/wordpress-content/uploads/2014/04/draft-mobile-registration-01.html. It uses software statements to carry data about the registration of a client with a certain authority into the client registration process.

[Tom Jones]

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.

[Torsten Lodderstedt]

How did you come to the conclusion it is intended to support apps on a phone only?

[Tom Jones]

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.

[Tom Jones]

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.

[Nat Sakimura]

Can we close this ticket and just send it to the Federation spec or dynamic client registration spec?

[Tom Jones]

you can close it for lack of support. Don’t bother to send it any where. it is just a limitation of the user experience that will need to be handled by other orgs.