RFC - Deceased or Incapacitated User Warrant

[zepatrik]

Problem statement

When people decease, become medically incapable for any reason, or are in any other way unable to take actions, there is usually a legal solution for this situation. Trusted people take over responsibility, someone heirs physical items, and someone gets ownership/decisive power over digital assets. In such cases it is often hard to impossible for successors to actually get an account deleted, cancel a subscription or access data.

Goals

Allow issuing warrants to other people without requiring them to sign up and manage an account just for this occasion. It also has to be:

1. flexible: passing these warrants should be possible in many ways
2. secure: provide the same level of security as the actual user authentication
3. autonomous: no interaction required by the account owner or provider

Non-Goals

1. deal with (local) law
2. make it too complicated to use

Comparable Existing Features

GitHub Successor

1. users can nominate a successor
2. successor has to have a GitHub account
3. successor has to agree to the nomination
4. specific to cases of death
5. successor gets permission to archive and transfer public repositories
6. death certificate or obituary has to be presented to support
7. is not legally binding

Drawbacks:

1. does not cover cases of coma, legal insanity, mental incapacity, ...
2. support is involved => slow, a lot of work, prone to social engineering attacks
3. legal documents are required

Facebook

1. allows removal or memorialization
2. covers cases of medical incapacity, ...
3. requires submission of legal documents to support that prove the condition of the person and that the requester is allowed to take action
4. only works with real name accounts

Drawbacks:

1. support is involved => slow, a lot of work, prone to social engineering attacks
2. legal documents are required

Google Inactive Account Manager

1. user defines the period after which an account is considered inactive
2. Google contacts the user multiple times over E-mail and SMS before any action is taken
3. inactive accounts can be configured to be automatically deleted
4. possibility to nominate up to 10 "trusted contacts"
5. trusted contacts can be allowed to access data (also partially)

Drawbacks:

1. actions can not be triggered immediately
2. inactivity detection might not trigger with some automation enabled (Zapier, IFTTT, App Script, ...)
3. no other way to trigger inactivity
4. trusted contacts are not verified
5. contact details of trusted contacts might change

Advantages:

1. fully autonomous, no legal documents required
2. data can be passed on
3. not limited to any kind of occasion
4. trusted contact is not required to have a Google account

=> Google's approach is the closest to our goals

Challenges we have to overcome

1. user needs trust in successor(s)
2. data may be split between multiple people or only shared partially
3. successor should not be able to act as the user
4. successor has to authenticate years or decades after the warrant was issued
5. law

First Implementation Ideas

Successor Authentication

1. turn key protocol where e.g. 3 out of 5 people have to cooperate (reduces trust in the individual)
2. long-term, securely storable physical keys (e.g. magnetic tape, printed on paper, physical device) that get passed on like any other physical item (global legal coverage, less prone to social engineering attacks)
3. using OAuth2 client impersonation

Successor Permission

As this is very application specific, it might be sufficient if Kratos differentiates between users and successors at the /whoami endpoint. This way the application and permission system take care of limiting the actions that can be taken.
Access to some self-service APIs will have to be configurable (e.g. deletion).

What we want to hear from you

1. any legal requirements and regulations you see or face regarding this topic
2. more technical ideas
3. concerns you have
4. general input about the feature

[cvvs]

Specifically in reference to identity assumption: Is this a feature which needs to exist in Kratos, or should it not be implemented by the organization or party which is using Kratos for authentication via some some other process?

Should such a feature be implemented, it would be important to periodically 'nag' the user to ensure this information is kept up to date.

[zepatrik]

Kratos has to technically allow this feature, as it handles everything around authentication, and this is a special case of authentication. This "keeping up to date" is definitely something we have to consider, e.g. Google does not care if the information you provide is correct and if it is updated regularly. When linking accounts, like GitHub does, it would be kinda safe to assume that people keep their account updated. Having printed backup keys, like you have for hard drive encryption, is the safest way to circumvent updating the information. From my experience, people will not update these information, even if you ask them to do so.

[github-actions]

I am marking this issue as stale as it has not received any engagement from the community or maintainers in over half a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• open a new issue with updated details and a plan on resolving the issue.

We are cleaning up issues every now and then, primarily to keep the 4000+ issues in our backlog in check and to prevent maintainer burnout. Burnout in open source maintainership is a widespread and serious issue. It can lead to severe personal and health issues as well as enabling catastrophic attack vectors.

Thank you for your understanding and to anyone who participated in the issue! 🙏✌️

If you feel strongly about this issues and have ideas on resolving it, please comment. Otherwise it will be closed in 30 days!

[aeneasr]

Marked as stale in error.

[gen1us2k]

Hello. This one is huge, and I think we need to cover as much as we can implementing this feature.
I did a little research about this field, and here are my findings:

Does GDPR apply to the deceased UK?
Is information about deceased individuals personal data? The UK GDPR only applies to information that relates to an identifiable living individual. Information relating to a deceased person does not constitute personal data and therefore is not subject to the UK GDPR.

[gen1us2k]

Consent given prior to death, is believed to extend beyond death.

However, relatives may have a different opinion, once their relative has died. This should be handled sensitively with relatives being encouraged to respect the deceased person's wishes (or in certain cases, their nominated representative/nominee, see below).

In legal terms, the General Data Protection Regulation (GDPR) and the Data Protection Act no longer applies to identifiable data that relate to a person once they have died.

However any duty of confidence established prior to death does extend beyond death. It is important to maintain confidentiality to ensure that trust in services and institutions are not undermined. Disclosure of confidential information post mortem therefore requires consent to extend the duty of confidence.

If you intend to collect tissue from a deceased person, to use tissue removed from the deceased or to conduct a post mortem purely for research purposes consent is required across the UK.

Tissue removed as part of a Coroner's / Procurator Fiscal's post mortem can be used for research, once they are no longer required for such legal purposes, however, consent for use in research must be in place.

Although legal details may vary between the nations within the UK, the same basic legal and ethical principles apply in terms of the consent required:

1. The person themselves can give consent for their tissues to be used for research prior to their death. If the person was not able to consent for themselves prior to death (due to lack of capacity), someone else may have been asked to provide consent, assent or advice on their behalf (visit 'Principles > Adults who are not able to consent for themselves').
2. Consent given before death should be respected, even when relatives may initially disagree.
3. If consent is not in place, and the person has not specifically refused prior to their death:
   3.1 In England, Wales and Northern Ireland an adult can nominate someone to represent them after their death and to give consent on their behalf. The nominated representative's consent cannot be overridden by other individuals, including those in a qualifying relationship.
   3.2 In Scotland a person can be nominated by anyone (aged 12 or over) before their death, to represent them after death. A nominee can then give authorization (equivalent to consent) on behalf of the deceased person.
4. If consent has not been sought from the above, the following can provide legally appropriate consent (or 'authorization' in Scotland) on behalf of the deceased person:
   4.1 In England, Wales, and Northern Ireland, those in a qualifying relationship.
   4.2 In Scotland, nearest relative.

Source: http://www.hra-decisiontools.org.uk/consent/principles-deceased.html

[gen1us2k]

HIPAA compliance says 'The HIPAA Privacy Rule protects the individually identifiable health information about a decedent for 50 years following the date of death of the individual.'

Source https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/health-information-of-deceased-individuals/index.html

Identification is not medical data and I'm not sure that this one is applies here, but I believe that input can be helpful

[gen1us2k]

I didn't find anything about the topic in ISO 27001 compliance. This one is about organizational security and it's not regulated here. I'm not sure how it can be regulated outside of the organization.

[gen1us2k]

Another finding of the GDPR after death https://www.twobirds.com/en/in-focus/general-data-protection-regulation/gdpr-tracker/deceased-persons

You can find a lot of regulations for EU countries

[gen1us2k]

I have a concern. Let's imagine that someone disabled their page on Facebook and accidentally died, but the user has a successor. The last wish of the dead user is to keep the memory as is and the successor should respect this wish and make this happen and activate the page.

In that case, I have a lot of open questions:

1. What legal documents do we need to get from the successor (which can change during the time)
2. How long do we need to store data in the database? (This one depends on the self-hosted or cloud Kratos solutions. I think that ORY can transfer the responsibility to the owner of the self-hosted solution)
3. Do we need to have the ability to restore the data in case of removal, respecting GDPR compliance
4. Put your own question here

[gen1us2k]

I'm not sure about how does IAM connects with HIPAA, because I'm new in HIPAA (I'll make research to get a better understanding of it). On the one hand, we do not need to take care of medical data. On the other hand, Kratos can be a gateway to the medical data (in that case it has to respect HIPAA compliance to use it in the US)

1. Does HIPAA apply after death? You can find more inputs about why one needs to store the data for 50 years (I think that this applies to medical data and I'm not sure that identification applies here). Read more here https://compliancy-group.com/does-hipaa-apply-after-death/
2. Disclosure of medical records https://www.cga.ct.gov/2013/rpt/2013-R-0124.htm
3. Who has rights of deceased patient's records https://journal.ahima.org/rights-to-deceased-patient-records/

[gen1us2k]

Amazon's experience about the topic:

1. https://s3.amazonaws.com/static.contentres.com/media/documents/cb8aa6dc-8908-4044-a240-53532453d672.pdf
2. Deceased customer account https://www.amazon.co.uk/gp/help/customer/display.html?nodeId=GZZQG845T3NKYX9D
3. https://mygoodtrust.com/articles/how-to-deactivate-an-amazon-account-when-someone-dies
4. https://www.joincake.com/blog/delete-amazon-account/

[gen1us2k]

Here are some of my suggestions, assumptions, and concerns

I talked to my lawyer, and I realized that legal issues regarding this issue are pretty simple in most countries, and the most complicated legal regulations are in the US. I'd recommend consulting with US law consultants because I have no idea how they manage it.

What data Kratos will store/process implementing this feature:

1. User's identity regulates by GDPR, ISO 27001, and some other regulations, but we need to remove personal data here, and we're fine.
2. In case of a user's death without consent to a successor, Kratos needs to store legal documents, death certificates, and any other documents. There are a lot of issues at this point that requires additional solutions (technical, legal, ethical). This one is huge for ORY as a company with many assets is a considerable risk in this case. (Image your own the worst-case scenario). (I'd recommend here to be HIPAA compliant)
3. Kratos needs to store some IDs to prove that the data was removed (I have no idea how to implement it yet. This one needs for ORY to be protected in any case of disaster)

I prefer to go with US law and HIPAA implementing this because both guys are most complex.

[aeneasr]

Thank you for all these thoughts and detailed input! @zepatrik is currently OOO but I am sure he will enjoy the discussion when he's back :)

[github-actions]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️