Handling credential issuer's that go offline
I raised this issue during IIW and I didnt feel i got a complete answer
I think that the credential use case requires adjustment of the spec to deal with credential issuer's that goes offline due to termination as an issuer, no longer being a going concern due to liquidation or similar event, rebranding, etc. In most of these cases the issued credentials are still valid.
If the Issuer goes offline the Entity Statement will no longer be available under the .well-known location. The spec says that trust can still be established by using the TA/Intermediary fetch and resolve endpoints.
Therefore i am looking for feedback on the following 3 suggestions:
- There should be additional exceptions added to 9 "Obtaining Federation Entity Configuration Information" for this case.
- Non-normative statements addressing the need for some federations to backup the Entity Configurations of their entities. I think that that the credential could look to refer to the federation fetch endpoint to use if the .well-known endpoint is not available. This seems related to `authority_hints` from an Entity Configuration, or `trust_anchor_id` of the OP uses when communicating to a client or resource server.
- Addition of claims to the Entity Statement that track historical trust in an entity or creation of a profile that refers to new claims that track trust establishment and termination over time such as `trust_validity: [{established_at: 1234832941, terminated_at: 1235833132}, {established_at: 1236001946}]`
thanks!
Comments (12)
-
-
- changed status to new
-
-
assigned issue to
-
assigned issue to
-
the PR that aims to concretely develop this analysis and resolve this issue is https://bitbucket.org/openid/connect/pull-requests/731
please Andres, join in the revision
-
- changed status to open
I'm confused by this issue, because the specification doesn't say anything about credential issuers.
Are you asking for some way to determine status of an Entity, Andres?
-
reporter Michael - I was trying to couch the request with respect to our use case in a VC issuing federation, but wherever you see issuer you can assume i mean Entity.
To restate the issue:
The use case is that the VC can be longer lived than the Entity that issued the VC, and yet the VC must still be able to be verified. In my mind these are the requirements
- The wallet and RP need to verify the VC using keys -
historical_keys
endpoint satisfies this requirement - The wallet and RP need to get the Entity’s revocation status at the time of issuing - PR 731 would satisfy this requirement
- The wallet and RP want access to the informational metadata of the issuing Entity - unmet
- There should be guidance on how the VC should be structured to access this historical information to promote inter-ecosystem interoperability - unmet
More background on the issue:
The requirement comes from the fact that our ecosystem is made up of entities like schools, colleges and employers that will terminate operations for a variety of reasons such as closure, bankruptcy or mergers. The termination of operations results in the .well-known location on their website also no longer being available. Our assumption is that the trust anchor and intermediaries will survive the Entity closure, so the information can still be retrieved
- The wallet and RP need to verify the VC using keys -
-
Thanks for the clear explanation!
-
Andres, hi!
Today we briefly talked about this issue, on the editors' call. The feeling is that we need to discuss this more thoroughly in order to come up with something that is well thought of, concrete and actionable. We’ll get back to this after we get the Implementer’s Draft out. In the meantime, if you have any comments or ideas, please post them here.
-
reporter Hi all, i would be happy to join a longer conversation about this issue when its next up. Dima - can I ask that you ping me when its on the agenda again, or we sync in advance of the call? Thanks!
-
There’s a working group call on Thursday at 7am Pacific Time. See the call schedule at https://openid.net/wg/connect/. We’d be glad to discuss it with you then.
-
reporter hey guys - im based on the east coast of Australia and tend to be start my first calls at 5 or 6am. 7am PT is my 12am and honestly I'm struggling to make the timeslot. Could I sync out of band with Giuseppe (or Dima) for this issue?
-
- changed status to closed
Closed due to federation content migration to Github. Replacement issue is at https://github.com/openid/federation/issues/9
- Log in to comment
Giuseppe De Marco recently talked about the idea to introduce a new endpoint / API to track trust changes in a federation over time. Similar to the historical keys endpoint.