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

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

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

Seems like profiles already contains confirmation methods, and we could have
more examples in there about how they get used.

I know we keep saying it, but I really do think this type of stuff is what
implementation guidelines are for, rather than making a big spec even
bigger.

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

Ok, will incorporate.

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

I can see why it's vague. I think Advice would be a bad name for something
you couldn't ignore. ;-)

Anyway, I'd support rewording on 572-574 to be clearer that "support its
use" means "willing to use" and not so much whether you understand the
advice. I think 1007-1009 are clearly the intent.

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

Yes.

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

I'll reword.

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

Well, I'm not sure...conditions defined in core really should have
consistent semantics, seems to me. I think we should discuss language on a
call to clarify this. I don't think it's substantive in the sense that
nobody's got significant "operational" code that uses this condition with
intermediaries.

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

Yes, it sounds unnecessary to me.

> Right, but how does authenticating authority relate to the identity
> provider and SAML authority.  Are they just three different terms for 
> the same thing?

Well, an identity provider for me is a precise thing, it's a SAML AA that
supports the Authn Request protocol. Some authenticating authorities may do
that, and some may not (leaving their involvement somewhat gray, much like
SAML 1.x AAs). In the authn context, all this is saying is "these SAML
authorities were involved".

In response to an AuthnRequest, one of the authorities involved is implicit
and not listed, the responding IdP. He's clearly both. The others, if any,
may or may not be IdPs.

[re Address attribute]
> Should we note somewhere that there is an assumption here that would need
> to be dealt with in a profile for interoperability?  

Don't know, my point was we never did before, and I don't know what the
cleanest way of including such language would be. I don't think it should be
specific to profiles like SSO that happen to reference the attribute.

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

The latter is likely to be an error (could be UnknownPrincipal, or not). The
former is usually a Success response with nothing in it, I think, but I
don't think we require that.

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

If you mean the XACML profile, I dunno if we would mention that. As far as
the SAML authz query, that one is basically couched as "requesting an
assertion meeting some criteria", I think.

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

Same as with the assertion, we don't define a specific relationship, not
that there isn't one. It's meant to be analagous.

> 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 guess it means "status of the fulfillment of the request"?

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

I think so, I seem to recall the old spec being more explicit about that
some place.

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

The elements in the AuthnRequest form the "template" set. The requirement is
that at least one SubjectConfirmation in the resulting assertion(s) can be
confirmed in a manner consistent with at least one element in that set. I'll
see if I can reword.

The basic idea isn't too hard, it's just a way to say "give me a holder of
key assertion about Bob with Alice's key". At which point policy at the IdP
kicks in, of course.

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

It's unclear, but it's talking about the root of the SAML object being
signed. I'll reword.

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

Don't recall the issue, it's old text from 1.1.

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

I don't think so, could you give an example that might suggest restriction
would make sense?

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

Basically. I might have a privacy setting that requires an SP to get
explicit permission for any SSO request it sends for me, and my IdP would
look for it.

-- Scott