RE: [security-services-comment] comment on SAML V2.0 Metadata: ContactPerson

["Scott Cantor" <cantor.2@osu.edu>]

> Section 2.3.2.2 describes how to specify basic contact
> information for a person.

All of that was imported close to verbatim from the Liberty ID-FF version,
and got little or no attention or interest during spec development. I'm
unaware of any significant usage beyond very minimal advisory purposes, so
asking about usage is not likely to produce any comprehensive advice, though
it may be worth asking people who used it there.

> The contactType apparently can be "one of" technical,
> support, administrative, billing and other.  This means that
> if the same person is, for example, both the technical and
> support contact, then there are two ContactPerson with the
> same elements present in both of them, but different
> contactType values?

Yes, that's how I've had to do it.

> Should there be guidance on representing an contact
> 'organizational role' in place of a contact person?
> E.g., it'd be nice to be able to express that
> "the IT department" at <Company> via <EmailAddress> is the
> "technical" contact.

I do that pretty routinely.

> Also, should there be guidance on
> representing the name of a contact person whose name does
> not have a natural division into "given" and "sur" names.

Probably would be a good idea to pick one as a recommendation in errata.

> Is there any chance of having an optional <Name> element
> within <ContactPerson> added to subsequent revisions of
> this document to address these situations?

Based on what I know, I don't think it's likely any subsequent revisions
will happen any time soon, and the schema can't really be changed in that
manner without breaking older implementations.

The general thrust of the schema was that when additional elements were
found to be needed, they would be defined to whatever precision people
wanted and then used in the Extensions elements. This could include elements
that supersede standard elements, and those particular, underspecified,
elements are optional, to make that easier.

> Is the value of <TelephoneNumber> an E.164 number (e.g.
> starting with a country code), or can be 'local' to a country
> or within a country? Should there be guidance on how additional
> information, such as a "telephone extension" or the indicator
> "mobile" or "text" be added to a TelephoneNumber: e.g. could
> they simply be part of the string, or must an XML attribute
> be defined for this purpose?

No attributes can be added to the element, so it's currently undefined and
intended solely for human consumption. It quite definitely can be anything
that remotely resembles a phone number, and the XSD data type of string is
all it's constrained to be.

-- Scott