Shibboleth Developers

[Tom Scavo <>]

On 4/18/05, Scott Cantor 
<>
 wrote:
> 
> eduPersonTargetedID is a problem for both profiles, and my proposal needs
> debate, particularly whether to start supporting a "new" syntax in the 1.x
> profile or just leave it imperfect and wait for 2.0. This depends to some
> extent on expected volume of use. But we need to decide quickly if a new
> syntax is to be supported in Shibboleth 1.3.

My gut feeling is that nothing new should be introduced at this time. 
Persistent identifiers abound in SAML2 so it seems best to wait and
see how that shakes out.

Attached are some notes and errata for the document posted yesterday. 
On the one hand, I appreciate the fact that two profiles were provided
back-to-back, but after a bit of reading it became clear that the two
have difficulty coexisting in the same document.

Tom
Document: draft-internet2-mace-dir-eduPerson-SAML-01

Errata:

- [line 42] Replace "([eduPerson])" with "[eduPerson]".

- [line 45] Replace "([SAMLCore])" with "[SAMLCore]".

- [line 45] Replace "([SAML2Core])" with "[SAML2Core]".

- [line 50] The word "implementations" is spelled incorrectly.

- [line 51] Replace "([ShibProt])" with "[ShibProt]".

- [lines 81--82] Replace "SAML 1.0 is identical to SAML 1.1 with respect to 
attribute representation and this profile should be considered to apply to it 
as well" with "With respect to attribute representation, SAML 1.0 is 
identical to SAML 1.1 so this profile applies to both specifications equally."

- [line 86, 273] Delete the period at the end of the line (which is not a 
sentence).

- [line 94] Delete the phrase "Unless specified below".

- [line 94] Typeset "oid" in a fixed-width font.

- [line 102] Delete the word "Unfortunately".

- [lines 110--156] Instead of listing the long names (which contain mostly 
redundant text), why not write the OIDs and the "friendly" names side-by-side?

- [line 168] Replace the period with a comma, and append the phrase "which 
are discussed in the next section."

- [line 178] In what namespace is the Scope attribute defined?  In other 
words, why is it unqualified?

- [lines 191--192, 291--292] Replace "Other attribute types must be addressed 
on a case by case basis at this time" with "Other attributes are addressed on 
a case by case basis below".

- [line 194, 294] Remove the quotes on the word "eduPersonTargetedID" and 
typeset it in fixed-width font.

- [line 195, 295] Replace "nor its semantics" with "nor are its semantics".

- [line 197] Typeset the word "eduPersonTargetedID" in fixed-width font.

- [line 198, 199, 298, 299] Replace the word "URI" with "unique identifier".

- [line 203] Put the URI on a line of its own.

- [lines 203--214] Replace these paragraphs with the following:

If the AttributeName attribute of the <saml:Attribute> element has value

urn:mace:dir:attribute-def:eduPersonTargetedID

then the <saml:AttributeValue> element MUST have a Scope attribute. For 
backwards compatibility, it is RECOMMENDED that the value of this attribute 
be set to the DNS domain of the identity provider (although other values are 
permitted).  The unique identifier of the service provider is not represented 
in this case.

If the AttributeName attribute of the <saml:Attribute> element has value

urn:oid:1.3.6.1.4.1.5923.1.1.1.10

then the <saml:AttributeValue> element MUST NOT have a Scope attribute.  
Moreover, the <saml:AttributeValue> element contain a <saml2:NameID> element 
with Format

urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

as described in section 8.3.7 of [SAML2Core].  The unique identifiers of the 
identity provider and service provider map directly to the NameQualifier and 
SPNameQualifier attributes, respectively.

- [line 206] Remove the comma and replace "possibly but not specifically a 
URI" with "but is often a URI".

- [line 206] Replace the word "value" with "identifier".

- [line 217, 311] Remove the quotes on word "givenName" and typeset the word 
in fixed-width font.

- [line 225, 321] Remove the quotes on word "eduPersonPrincipalName" and 
typeset the word in fixed-width font.

- [line 234, 332] Remove the quotes on word "eduCourseOffering" and typeset 
the word in fixed-width font.

- [line 244, 341] Remove the quotes on word "eduPersonTargetedID" and typeset 
the word in fixed-width font.

- [lines 278--279] Join these two lines.

- [line 287] Define "COTS".

- [line 297] Typeset "eduPersonTargetedID" in fixed-width font.

- [line 345] Insert 'FriendlyName="eduPersonTargetedID"' into the 
<saml2:Attribute> tag.


Comments/Suggestions:

- Define the xsi: prefix in section 1.1.

- Reorganize section 2.2.  Move lines 91--93 to the end of the section, after 
the current line 100, and join lines 90 and 94.

- In section 2.2, the value of the AttributeNamespace attribute is a 
Shibboleth-specified URI.  Is this profile expected to interoperate with 
other SAML 1.1 implementations?  If so, this URI should be generalized 
(although I'm certain you won't want to do that for backward compatibility).

- Why does section 2.2.2 deviate from section 8.2.2.1 in [SAML2Prof]?

- The inclusion of an eduCourse attribute in a document describing eduPerson 
attributes is curious.  That said, the "eduCourseOffering" example in section 
2.4 cries out for a complex content model.

- In section 3.1, the dependence on the X.500/LDAP attribute profile in 
[SAML2Prof] should be spelled out.

- Observation: The first example in section 3.4 is identical to example 8.2.6 
in [SAML2Prof].

- Thought experiment: If you were starting from scratch (i.e., if eduPerson 
were being released for the first time) would section 2 be written 
differently than it is now?  There probably wouldn't be any mention of 
"scoped attribute value", for instance.  So perhaps those portions of the 
SAML1 profile that give way in the second profile should be clearly marked as 
"deprecated".

- The alternative representation on lines 207--214 does not seem to solve the 
problem (which itself is not clearly defined).  Moreover, the wording 
suggests the inclusion of a <NameID> element in this context is specified by 
[SAML2Core], which I don't think is the case.  For these reasons, I would 
avoid the alternative representation at this time.

- Who is the intended audience of this document?  Would an arbitrary SAML 
implementation be able to leverage eduPerson by following this document?

- Is this a Shibboleth profile or a SAML profile?  (Although references to 
Shibboleth are cleverly disguised, this really is a Shibboleth profile and 
should be labeled as such.)

- If you think of eduPersonTargetedID as a name identifier (which it is in 
SAML2), then the exceptional nature of this "attribute" is less dramatic.