Contradictions around unicity of IFIs ?

[Lctrs]

An Inverse Functional Identifier (IFI) is a value of an Agent or Identified Group that is guaranteed to only ever refer to that Agent or Identified Group.

So, if I understand this correctly, an IFI must be unique to an Actor (either an Agent or a Group).

Problem is that the spec never requires LRS providers to reject an incoming Group that share the same IFI of an existing Agent.

An Agent SHOULD NOT use Inverse Functional Identifiers that are also used as a Group identifier.

An Identified Group SHOULD NOT use Inverse Functional Identifiers that are also used as Agent identifiers.

So imagine the following scenario :

1. The LRS provider receives the following statement (via a POST request) :

{
    ...,
    "actor": {
        "objectType": "Agent",
        "mbox": "mailto:joe@example.com"
    },
    ...
}

The provider creates and store a new Agent with the provided mbox value.

2. Later, the provider receives the following new Statement (against via a POST request) :

{
    ...,
    "context": {
        ...,
        "team": {
            "objectType": "Group",
            "mbox": "mailto:joe@example.com"
        },
        ...
    }
}

What to do in such a case ? Rejecting with a 409 Conflict ? Use the existing Agent instead of the received Group (if I understand the code correctly, that's what ADL's LRS seems to do), implying that the context's team could sometimes be an Agent and thus contradicting with the spec ? Other ?

[garemoko]

I'd have to check the rest of the spec, but from the parts you quoted it sounds like this is something that's the responsibility of the LRP to get right, rather than the LRS to enforce. Really this is the same as the fact that the LRS can't enforce that the same identifiers aren't re-used to represent two different people, but there are still big problems that will arise if they are.

[andyjohnson]

The rationale behind not rejecting Statements by the LRS is that the LRS is expected to go beyond this measure to avoid duplicate identifiers. The LRS would also be likely to want to avoid doing a bunch of lookups for conflicts when we are simply trying to write to the LRS (although not so much so that we explicitly disallow it). The fact that the spec calls these fields out as unique means that the LRS is expected to "clean up" in the case of duplicates, whether they come in at run-time, through a data merge (also beyond the scope of the spec), etc. Something like this I would hope be handled the the LRP at the time it is creating a user and before it starts grabbing that identifier and producing Statements with it.

[andyjohnson]

With that said, it probably is a good idea to explain this concept better and point out specific circumstances like @Lctrs has found.

[fugu13]

@garemoko is correct, and part of the reason is to prevent the need for checking, and part of the reason is historically agents and groups were much closer, so we kept the strictures looser.

It is absolutely not the case that the LRS is expected to "clean up" in the case of this issue, and any LRS that does so for this after the fact would be in violation of the spec.