Closed OIDF-automation closed 2 weeks ago
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.
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
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?
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
historical_keys
endpoint satisfies this requirementMore 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
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.
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.
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?
The OpenID Federation Extended Subordinate Listing contains timestamps for particular status changes. It doesn't have an explicit status value.
Cc: @MichaelFraser1999
This work can be done in the now-adopted specification https://openid.net/specs/openid-federation-extended-listing-1_0.html .
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/2147
Original Reporter: sloops77
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:
thanks!