Refeds


Subject Re: entity categories
From "Cantor, Scott" <cantor.2@xxxxxxx>
Date Tue, 25 Jun 2013 16:23:22 +0000

On 6/25/13 12:04 PM, "Benn Oshrin" <benno@xxxxxxxxxxxxx> wrote:
>
>The first problem occurs if I, as a VO, want to map these attributes
>into the RFC4519 person object class. person requires sn and cn. (This
>by itself is a problem, as IME when a person only has one name it is
>considered givenName, not sn.) In the R&S context, if a person has only
>one name, should I expect it to be delivered via displayName exclusively?

The problem is that, as in everything, nobody will agree to insist on
anything. I would have argued for displayName only, but then any site that
doesn't support it was left out (and vice versa if we required separate
fields).

We ruled CN out entirely, because it is in no way consistently populated
by organizations as a name.

>Alternately, if a person has two (or more) names and I receive
>displayName, how do I know how to parse the name suitably for the person
>class? Do I just copy the whole thing into sn? That seems wrong. Do I
>guess based on whitespace? That seems likely to fail.
>What if I want to receive multiple encodings of the same name? (Japanese
>being an example where this could happen.)

I think the point is whether R&S means to support non-display use cases
for name, including non-contrived population of LDAP. I would say it does
not right now, intentionally.

>(To work around these issues as is, I'd probably just prepopulate these
>values into a form and require the user to fix them up as needed.)

I think that's a bad idea, leading to essentially carte blanche
impersonation of users in many applications. As I've said before, I would
never intentionally allow self-update of name fields in a federated
application that displays the fields as the primary means of attribution
or person selection.

-- Scott