Handling credential issuer's that go offline

[OIDF-automation]

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:

1. There should be additional exceptions added to 9 "Obtaining Federation Entity Configuration Information" for this case.
2. 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.
3. 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!

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: vdzhuvinov

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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

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

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: mbj

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?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: sloops77

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

1. The wallet and RP need to verify the VC using keys - historical_keys endpoint satisfies this requirement
2. The wallet and RP need to get the Entity’s revocation status at the time of issuing - PR 731 would satisfy this requirement
3. The wallet and RP want access to the informational metadata of the issuing Entity - unmet
4. 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

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: mbj

Thanks for the clear explanation!

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: vdzhuvinov

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.

‌

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: sloops77

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!

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: mbj

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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: sloops77

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?

[selfissued]

The OpenID Federation Extended Subordinate Listing contains timestamps for particular status changes. It doesn't have an explicit status value.

Cc: @MichaelFraser1999

[selfissued]

This work can be done in the now-adopted specification https://openid.net/specs/openid-federation-extended-listing-1_0.html .