Handling credential issuer's that go offline

Issue #2147 closed
Andres Olave created an issue

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!

Comments (12)

  1. Vladimir Dzhuvinov

    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.

  2. Michael Jones
    • 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?

  3. Andres Olave 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

    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

  4. Vladimir Dzhuvinov

    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.

  5. Andres Olave 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!

  6. Andres Olave 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?

  7. Log in to comment