Comments and Questions on Core-02

["Metz Rebekah" <metz_rebekah@bah.com>]

Hi all - 

I sat down with the spec for a deeper read-over last night and came up with
a few questions so far.  I've tried to search the email archives to find the
threads of discussion on these questions, but the capabilities on the oasis
site seems to be currently offline.  I hope that someone can point me in the
correct direction for TC resolution on these late-coming questions.

Quick nit on the contributor list:  
I'm now affiliated with Booz Allen Hamilton rather than NASA.  Note that it
is Booz (not Booze) as is used for my colleague Rick Randall =)


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? 

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?

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

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

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

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.  

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?



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?

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?

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

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?

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


I'm going to re-read the rest of Section 2 tonight and post additional
comments/questions then

Thanks for the insight

Rebekah

Rebekah Metz
Associate
Booz Allen Hamilton
Voice:  (703) 377-1471
Fax:     (703) 902-3457