Support Legal Entities

Tom Jones

There is a lot of confusion in this area.

a business name is typically a legal name and in some countries they are legal persons
if you mean legal name of natural person - they say that
It is important when creating 2 to use “family names” and “given names” if there is to be any breakdown, otherwise there will be problems with eastern conventions. In no case should the term “middle name” appear.
use the term “enterprise name” rather tan “business name” as some institutions are not businesses
You may need to distinguish been trade name and legal name for enterprises as well.
If possible these should all be URIs (right i know that is hard but it would help)

2019-07-14T17:03:51+00:00

Adam Cooper

What I am referring to is that an identity may not always be a representation of a natural person. In some cases, as in EU law, a legal person may act on behalf of an organisation (e.g. a business). The eIDAS Regulation is an example of this across the EU where an entity may authenticate legitimately as a legal person without disclosing anything other than the legal name of the organisation and a unique identifier, this would then be used to transact with the relying party. A natural person may represent a legal person but this is not always the case. Commission Implementing Regulation (EU) 2015/1501 contains within its annex definitions of attribute sets for the unique identification of natural and legal persons. Given that this is established in EU law we could do worse than refer to it - https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AJOL_2015_235_R_0001

2019-07-15T12:36:25+00:00

Torsten Lodderstedt reporter

I can imagine how we could express the fact that a natural person represents a legal entity, but I’m currently lacking the understanding how this would work for a legal entity (or a machine acting on behalf of this entity).

How does a legal entity authenticate itself? I’m asking because all data in an OIDC assertion are about a certain subject (sub claim) that the OP somehow authenticated.

2019-07-15T12:52:53+00:00

Jim Willeke

“Legal Person in legal context typically is a person (or less ambiguously, a legal entity)—whether human or non-human—that is recognized as having certain privileges and obligations such as the legal capacity to enter into contracts, to sue, and to be sued.” (https://en.wikipedia.org/wiki/Legal_person) Wikipedia also has a List of Legal Entities by Country: https://en.wikipedia.org/wiki/List_of_legal_entity_types_by_country

So perhaps the term Legal Entity which would appear to cover any “Legally” defined entity.

Organization seems a better fit than “enterprise” as not all Organizations are “Businesses”. (NGOs, Non-profit, etc)

A legal “Organization” can only act by way of a Natural Person, which is an Agent of the organization, as the Organization can not sign a document or file a legal motion.

2019-07-15T13:26:53+00:00

Adam Cooper

Legal Entity is a good term. It is also true that in most cases a Natural Person will be acting for the Legal Entity.

2019-07-15T20:32:49+00:00

Tom Jones

Something is getting lost here. As i understand it, GDPR only applies to natural persons (some lawyer might step in here.) So it is important when describing purpose and other fields to know what sort of entity is being authenticated. Somehow i think the point of this doc was natural persons. Which ever it is, the doc needs to clarify its purpose.

2019-07-16T00:10:34+00:00

Jim Willeke

I believe that you must be referring to the GDPR Recital 14 “The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data.”

GDPR does NOT apply to “Personal data” about a company.

Personal Data only refers to Natural Persons. Companies (Organizations) do not have personal data, but they do have confidential data.

2019-07-16T08:06:15+00:00

Tom Jones

Which is the problem - nothing i have seen in OpenID anywhere actually allows a relying party to determine if the sub, or anyother id should be treated as a natural person. Yet this is a legally critical distinction for that relying party. That is why if these new terms are included, it must crystal clear to the relying party if legal protections (such as the GDPR) should apply to the entity behind the identifier.

2019-07-16T15:38:18+00:00

Nat Sakimura

Post implementer’s draft.

2019-07-18T14:48:34+00:00

Torsten Lodderstedt reporter

postponed until we have finalized current spec

2020-01-15T15:54:00+00:00

Torsten Lodderstedt reporter

changed status to on hold

2020-01-25T11:52:05+00:00

Torsten Lodderstedt reporter

changed status to open

started discussion about new topics (since we are about to enter implementers draft 2)

2020-03-17T11:07:38+00:00

Torsten Lodderstedt reporter

I started to write down use cases for this topic. Please review and comment.

https://docs.google.com/document/d/1HyVg3uDW879kLIuEoqjWMEejmqEYkmRhKThY7KlUIVU/edit

2020-03-17T11:08:38+00:00

Torsten Lodderstedt reporter

changed title to Support Legal Entities

2020-03-17T11:12:24+00:00

Steinar Noem

A “legal person” or entitity would typically authenticate itself by using a seal (digital signature).

Regarding privacy: the lawful basis of processing data is based on the reason an entity has for processing personal data. In health care this is linked to the services a legal entity provides.

A little bit simplified perhaps, but a hospital has the lawful basis of processing personal health data because it treats patients.

2020-03-19T19:21:30+00:00

Mark Haine

Hey @Steinar, would you add your use case to the document that Torsten has linked above.

I would also add that it is often the case that a legal entity doesn’t act for itself and I am not a massive fan of the QSealCert in eIDAS for authenticating a Legal Entity. It seems to me that there is usually something acting on behalf of the Legal entity in the form of a member of staff (Natural Person) or a thing such as an application instance.

2020-03-30T16:27:03+00:00

Torsten Lodderstedt reporter

changed milestone to Implementer's Draft 3

2020-05-05T06:20:30+00:00

Mark Haine

assigned issue to

Mark Haine

2020-07-06T13:03:35+00:00

Mark Haine

By wayof an update I have been working on a draft and as part of that I have prepared a coupkle of example response json documents:

‌

This is the example I presented at the previous working group meeting where Jane Brown has been appointed as Official Receiver by a court:

{
    "sub": "JBrown",
    "email": "janebrown@example.com",
    "verified_claims": {
      "verification": {
        "trust_framework": "entity_claims_example_framework",
        "time":"2020-04-23T18:25Z",
        "verification_process":"f24c6f-6d3f-4ec5-973e-b0d8506f3bc7"
      },
      "claims": {
        "given_name": "Jane",
        "family_name": "Brown",
        "birthdate": "1986-01-26",
        "authority": [ {
            "applies_to": {
                "company_name": "Dontpaymybills Limited",
                "company_number": "12341234",
                "jurisdiction": "england-wales"
            },
            "permission": [ {
                "role": "Official Receiver",
                "validity":[ {
                    "start": "2020-05-01T09:00Z",
                    "end": "2020-11-01T18:00Z"
                    }]
            }],
            "granted_by": {
                "method": "appointment",
                "granting_body": "High Court London",
                "reason": "Winding up Order issued"
            }
        }]
      }
    }
}

‌

I have also created an example where the eKYC IDP is presenting subject Bob Smith who is Official Director of the example company:

‌

{
    "sub": "BSmith",
    "email": "bobsmith@example.com",
    "verified_claims": {
      "verification": {
        "trust_framework": "entity_claims_example_framework",
        "time":"2020-04-23T18:25Z",
        "verification_process":"f24c6f-6d3f-4ec5-973e-b0d8506f3bc7"
      },
      "claims": {
        "given_name": "Bob",
        "family_name": "Smith",
        "birthdate": "1981-01-26",
        "authority": [ {
            "applies_to": {
                "company_name": "Example Company Limited",
                "company_number": "12351235",
                "jurisdiction": "england-wales"
            },
            "permission": [ {
                "role": "Director",
                "validity":[ {
                    "start": "2018-03-02T10:00Z"
                    }]
            }],
            "granted_by": {
                "method": "appointment",
                "granting_body": "Companies House",
                "reason": "Official company officer"
            }
        }]
      }
    }
}

‌

2020-08-12T14:30:18+00:00

Steinar Noem

Nice Mark! I have a couple of questions:

I see you have used “authority” and “applies_to” to distinguish between the subject and the legal entity that the subject represents. Would it make sense to be more specific for the claim type? E.g. “legal_entity”, or “juridical_person”? I know those are concepts/words from the world of law, but the reason for needing this representation often comes from legislation or legal requirements.

I wonder if there should be a “country” claim with values/names defined by ISO 3166-1 (and possibly ISO 3166-2) to indicate in which country the legal entity is registered in the “applies_to” claim structure.

Also, I guess in some cases something like an ISCO-08 (job) code could give additional value. This could be indicated in the “permission” claim for that Bob guy above.

“permission”: [ {

“role” : “Director”,
”code”: “OC1120”.
”system” : “ISCO-08”

8< …

‌

2020-08-12T16:11:57+00:00

Alberto Pulido Moyano

Hi Mark, In my opinion all the elements in your sample response document make sense, however I think that we could apply here some principles to decouple some of the components. By doing that, your proposal could be easier to integrate/plug-in (and here I think implementors feedback would be fundamental!).

I also think that your proposal for representing authority proof itself could become an independent extension, applicable not only to verified claims.

The way I see this could work better is by having company related claims together with the rest of subject related claims. At the end, for the RP they are just another pieces of information they are requesting.

The authority proof itself could become a separate element (I took the liberty to change the name!), in my opinion outside verified claims, since the RP may not be interested in requesting verification for some of them. Which makes me think we may need to extend the types of evidence documents types applicable for legal entities, including probably evidences for the authority proof (or maybe that is too much!).

‌

So here is a tweaked version of your sample response document including the changes proposed above:

{
    "sub": "BSmith",
    "email": "bobsmith@example.com",
    "verified_claims": {
      "verification": {
        "trust_framework": "entity_claims_example_framework",
        "time":"2020-04-23T18:25Z",
        "verification_process":"f24c6f-6d3f-4ec5-973e-b0d8506f3bc7"
      },
      "claims": {
        "given_name": "Bob",
        "family_name": "Smith",
        "birthdate": "1981-01-26",
        "company_name": "Example Company Limited",
        "company_number": "12351235",
        "jurisdiction": "england-wales"

      }
    },
     "authority_proof": [ {
            "applies_to": {
                "company_name",
                "company_number",
                "jurisdiction"
            },
            "permission": [ {
                "role": "Director",
                "validity":[ {
                    "start": "2018-03-02T10:00Z"
                    }]
            }],
            "granted_by": {
                "method": "appointment",
                "granting_body": "Companies House",
                "reason": "Official company officer"
            }
        }]
}

And here a sample request to ask for authority proof for the legal entity related claims:

{
    "userinfo": {
      "email": null,
      "verified_claims": {
        "verification": {
          "trust_framework": "entity_claims_example_framework"
        },
        "claims": {
          "given_name": null,
          "family_name": null,
          "birthdate": null,
          "company_name": null,
          "company_number": null,
          "jurisdiction": null
        }
      },
      "authority_proof":{
        "company_name": null,
        "company_number": null,
        "jurisdiction": null
      }
    }
}

I hope this helps!

2020-08-18T20:35:17+00:00

Mark Haine

Hi Steinar,

I used “applies_to” rather than being specific about the type of entity as I think that this approach could permit a more generic way of representing authority between any two entities. It could be a case that an IDP might want to communicate a power of attourney of one natural person over another.

2020-08-19T14:20:09+00:00

Mark Haine

Hey Alberto,

I think there is a problem with your suggestion in that the authority_proof is not contained within the verified_claims. Is that what you intended? I think that implies that the authority proof is not verified.

It seems to me that the authority (or authority_proof) is very much a claim that should be verified in an eKYC context.

2020-08-19T14:27:17+00:00

Alberto Pulido Moyano

Hi Mark,

It was intentional just to reflect exactly what you just said, at the end I see it just like any other claim, whether it is verified or not is up to the RP to request that. Actually, I think that my example for requesting the authority_proof should be different, so let me include the same example asking for verification of the authority_proof:

‌

Request:

{
    "userinfo": {
      "email": null,
      "verified_claims": {
        "verification": {
          "trust_framework": "entity_claims_example_framework"
        },
        "claims": {
          "given_name": null,
          "family_name": null,
          "birthdate": null,
          "company_name": null,
          "company_number": null,
          "jurisdiction": null,
          "authority_proof": null
        }
      }
    }
}

Response:

‌

{
    "sub": "BSmith",
    "email": "bobsmith@example.com",
    "verified_claims": {
      "verification": {
        "trust_framework": "entity_claims_example_framework",
        "time":"2020-04-23T18:25Z",
        "verification_process":"f24c6f-6d3f-4ec5-973e-b0d8506f3bc7"
      },
      "claims": {
        "given_name": "Bob",
        "family_name": "Smith",
        "birthdate": "1981-01-26",
        "company_name": "Example Company Limited",
        "company_number": "12351235",
        "jurisdiction": "england-wales",
        "authority_proof": [ {
            "applies_to": {
                "company_name",
                "company_number",
                "jurisdiction"
            },
            "permission": [ {
                "role": "Director",
                "validity":[ {
                    "start": "2018-03-02T10:00Z"
                    }]
            }],
            "granted_by": {
                "method": "appointment",
                "granting_body": "Companies House",
                "reason": "Official company officer"
            }
        }]

      }
    }
}

‌

2020-08-19T15:03:55+00:00

Kai Lehmann

We are dealing with legal entities as customers for De-Mail and I would like to offer a few comments to this topic:

‌

In Germany we also have the construct of a legal entity being represented by another legal entity which in turn can be represented by a natural person. So there are in fact representation chains possible, I do not know to what depth this is possible or though.
We support not only companies as legal entities, but also public authorities/agencies
A legal entity has a specific type. Depending on the legal type, the entity is registered at a specific registry (a registry has a specific type as well as a location). Upon registration the legal entity receives a number under which the entity is enlisted in the registry.
Some legal entities are as small as single persons having a small owned business. Those legal entities might not even be registered in public registries and might not have a formal number in such official registers. Those legal entities are allowed to create an account by basically self certifying (and signing for it) that they are who they claim to be.

‌