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

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

Comments inline...I've put the line numbers from draft 2e, dated 12 November
with my response.  I added have a few more questions at the end from the
remainder of the document.

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

 

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu] 
> Sent: Wednesday, November 17, 2004 10:06 PM
> To: 'Metz Rebekah'; security-services@lists.oasis-open.org
> Subject: RE: [security-services] Comments and Questions on Core-02
> 
> > 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.
> 

Does it make any sense to point the reader of the spec to a source (such as
the token profile) that captures/addresses these issues?

> > 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 
> relationship"
> rather than "no relationship". We don't mean there is none, 
> only that it's not defined in core.
> 

I like the addition of "no specific relationship" to more clearly state that
intention.

> > 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.
> 

(Lines 572-574) So my confusion was on what is implied for the situation
where advice is present and supported by the application.  Is the
application *required* to use the advice or does it have a choice?  I read
lines 1007-1009 to clearly state that the application has a choice, when
supported, to ignore or use the Advice.  Lines 572-574 seem to say that an
application can ignore Advice only when it doesn't support use.  

Therefore, when defining support for conditions, is it lines 864-866 that
are saying that if conditions are not supported, an assertion is
Indeterminate?

> > 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?

These are lines 904-906 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....

I assume that then the TC will come back to this in the future, if necessary
then and for now it falls into the category of "the semantics are how you
agree they should be"?

> 
> > 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).

By "other line" you mean 1012-1013?  This is the only place that lax
processing stuck out.  I'm in favor of consistency.
> 
> > 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.

Right, but how does authenticating authority relate to the identity provider
and SAML authority.  Are they just three different terms for the same thing?
I found myself having a hard time keeping straight when they referred to
different entities vs. the same entity. +1 for vetting their use.
> 
> > 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.

Should we note somewhere that there is an assumption here that would need to
be dealt with in a profile for interoperability?  

> 
> > 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.

So in response to a request for all attributes for a particular subject
where no attributes can be returned, the assertion would contain no
attribute statements?  This response would be the same for a request for
attributes about a subject that itself is unknown?
> 
> -- Scott
> 
> 

Lines 1405-1412:  SAML protocols also achieve the action of requesting an
authorization decision.

Lines 1480-1485:  Does core purposely not define a relationship between the
entity that generated a request message and the requester (i.e. between
Issuer and Signature)

Lines 1601:  It seems a bit awkward to talk about a status response in terms
of the request status?  Is it the status of the exchange?  I follow that the
response, which provides a status, is communicating information about a
particular request.  I see how the status also applies to the response,
which together with the request forms an exchange.  

Line 1716-1730: Is it a purposeful decision that an assertion request cannot
request all assertions for a particular authority be returned?

Lines 1941-1943:  Can you explain what "confirmed in the manner described by
at least one element in the requested set" means?  What elements comprise
that set?

Line 2897:  Is the enclosing root element the SAML root (i.e. assertion or
protocol message that is signed)?  Is the message mentioned in 2900 the XML
document that contains the assertion/protocol message or is it referring to
the assertion/protocol message?

Lines 2922-2923:  Why is this called out here?  It is not clear how the text
addresses the title?

Lines 3063-3093:  Are there any restrictions on how encrypted elements can
be used in combination with each other?

Lines 3334-3350:  Are Prior, Implicit and Explicit intended for use when
more detailed information than simply "Obtained" is necessary ?

I think that is it. 

Rebekah