RE: [security-services] Comments and Questions on Core-02

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

> I've been working my way through the discussions on
> <SubjectConfirmationData> and claims that has occurred over the past few
> days.  There seem to be much discussion and understanding on the
> relationships inferred by those statements.  Is there a place (other than
> the list discussions) where the assumptions about and specification of
> those relationships is stated? 

My guess is the SAML token profile is a good place to start, along with some
of the early discussion on the holder of key language. You can quite easily
see that the issue here is permitting impersonation. So any language that
even begins to try and equate the subject and the confirming/attesting
entity is just wrong now.

> Lines 524-526 "...This specification defines no relationship between the
> entity represented by this element and the signer of the assertion (if
> any)." and lines 555/6 "...which provides both authentication of the
> issuer..." & lines 561/562 "... Relying party SHOULD evaluate the
> signature to determine the identity of the issuer..." seem to read as a 
> contradiction that I'm tripping over during my read-through.  What am I
> missing in interpretation here?

There's obviously some relationship, and you have to know what it is and
evaluate it, but the first sentence just says that we don't define what that
relationship is in core. In other words, it's out of scope how to meet the
SHOULD.

Another way to look at it is that if you don't know how to do it, you're
probably doing something wrong because you didn't define enough of the
details in your deployment. Thus the SHOULD.

Maybe the first sentence should be "no specific or particular relationsip"
rather than "no relationship". We don't mean there is none, only that it's
not defined in core.

> Lines 533:535  Is it intentionally left unspecified whether <Advice> can
> be ignored by an application if that application supports its use?    

My recollection is this came up again lately, when Conditions were
discussed, and that we concluded Advice is completely optional. If the stuff
in there has mandatory processing semantics, it should be a condition.

> Line 687:  How is the network address formatted, or is it left to a
> profile to specify?

We didn't do it in 1.0, so I didn't do it here, other than to change the
name so that it wasn't IP specific. I can't see any place to do it in a
profile now except as a profile itself (i.e. here's how to do IP, here's how
to do Foo, etc.)

> Line 732-733:  Can attributes from other namespaces also still appear in
> elements of the KeyInfoConfirmationDataType or only the optional
> attributes defined in SubjectConfirmationDataType?

The schema doesn't have a wildcard in it, so no. And the text confirms this
by not stating that anything else is legal. I assumed extensions that needed
more functionality could define their own types or even derive from this
extension and add the wildcard back.

I should probably relax the language so that it says to use this type "or a
type derived from it" to represent ds:KeyInfo data.

> Lines 840-841: At first read (or first couple of reads for me) the last
> line of the paragraph seems to imply that the audience element 
> should carry a Format attribute.  

Which line is this in cd-02e?

> Section 2.5.1.4 (Lines 866-896):  How does OneTimeUse play out over
> intermediaries between the issuer and the intended audience?  
> If there are multiple relying parties, are the semantics to be that the 
> assertion is used once or once by each member of the audience?

My take would be that if it's "used" by an intermediary, it's done and can't
be forwarded, but since we have no profiles yet that use either SAML
intermediaries or this condition....

> Lines 944-945:  Is there a reason that the sentence "If elements from
> non-SAML namespaces are used, lax schema validation must be used when
> processing the elements" is included here, but not at line 710?

No. We should take the other line out, IMHO, since it's apparent in the
schema, and if you don't know that from looking at it, it wouldn't mean
anything to you anyway (because you're not validating).

> Lines 973-974:  Line 944 couches the AuthnContext elements in terms of the
> identity provider.  Is there any claim regarding the relationship between
> the SAML authority "...asserting that the assertion subject  was
> authenticated..." and the identity provider? On a similar note, line 984
> uses the term authenticating authority; is this another term for the same
> entity?

I think 944 should be changed. This is part of what Rob wanted done, vet all
the uses of these terms. Authenticating authority just means what it says,
an "authn authority that participated". Sort of an active term.

> Line 1031:  Is it left to a profile to specify the representation of
> address (ip address; domain name, mac address, etc.)?

See above. We've never done it anywhere, people just assumed. It's certainly
not a domain name, since there's a separate attribute for that.

> Lines 1045-1083 (Section 2.7.2.2):  Would it make sense to move the
> statement about finding further information re: AuthnContext to this
> sub-section?

I would just copy it.

> Lines 1090-1105:  Why must an attribute statement have at least one
> attribute?  

Cause why bother otherwise? It would be an empty statement. Although, that
has some interesting properties during implementation if you do things like
filter attributes out. You have to sanity check the object and sort of
destroy it from the inside out.

Might be worth relaxing this if enough people are doing that, I figured it
was unique to me.

-- Scott