Re: [security-services] Days late and dollars short,comments on "entity" terminology

["Eve L. Maler" <Eve.Maler@Sun.COM>]

Thanks a bunch for going over these so carefully.  I still plan to 
finish this exercise for all the specs; am struggling to clear a few 
hours to continue on it.  I am also responsible for implementing any 
agreed-on cleanup items, but I'm trying to stay away from anything 
remotely substantive or complicated.

Responding to selected replies of yours...  By the way, if anyone at 
home wants to play along, the rev in question is this one:

core-02g-diff:
http://www.oasis-open.org/apps/org/workgroup/security/download.php/10391/sstc-saml-core-2.0-cd-02g-diff.pdf


Scott Cantor wrote:
>>SAML authority:
>>core-02g-diff
>>***8.3.6, 3364: not sure why there is coyness here about saying
>>the entity is either a SAML authority or some other participant
>>in a SAML profile; reword more boldly?
> 
> I'd have to see what you propose. I'm not sure what you read as coy, it was
> just trying to note that a SAML authority is one possible system entity, but
> so is a SAML Requester or Responder.

The coyness was in the use of "SAML authority" as a mere example of an 
entity that provides SAML services, when that's pretty much the 
definition of a SAML authority.  The requester/responder distinction 
seems to be one level of indirection "up" from whether you're an 
authority or some other participant in a profile.  It almost sounds like 
we mean to say "an entity that has an operational mode as defined by 
SAMLConform" here, but that's not as helpful.

Since it probably doesn't make sense to spend a ton more time on this 
issue, though, would this work?

"Indicates that the content of the element is the identifier of an 
entity that provides SAML-based services (such as a SAML authority, 
requester, or responder) ..."

>>***2.2, 406: in talking about assertion and message issuers, it's
>>clear but it's a novel use of issuer; OK? Oddly, "issuer" is
>>nowhere in the glossary; should it be?
> 
> I would maybe reword as "for subjects and the issuers of assertions and
> protocol messages". Probably it should be in the glossary.

I can reword.  Jeff, what do you think re the glossary idea?

>>***2.3.3, 597: OK (though I question the usefulness of the SHOULD
>>here)
> 
> 
> Arguably it ought to be a MUST. I felt compelled to say something. The point
> was to make people that want to have Issuer = "Fred" think twice about it.

Nah, SHOULD is cool since as stated it's untestable (and I don't want to 
be messing with SHOULDs vs. MUSTs at this stage unless we've got a 
serious ambiguity).

>>***3.4 and subsections: should request issuer be simply
>>requester, for simplicity and consonance with our protocol
>>terminology? note that it appears very frequently!
> 
> I've hesitated to make changes here mostly because it's fragile, important,
> and I didn't want to break anything. Of course, if I'd just done it before
> the second review, no big deal, but I didn't know we'd have that much time
> to cross check it.
> 
> I can't *think* of any reason that using requester (meaning SAML requester,
> of course) would be wrong. If you want to make the change, I'll read it over
> thoroughly.

Let's not bother.  The meaning isn't confusing, though people may wonder 
why we've got two terms for one concept.  We can clean this up in a 2.x 
or something.

>>***2.4.1.2, 767: OK (but shouldn't this say that *in this case*
>>the presenter is known as the confirming entity, rather than
>>saying i.e.?
> 
> I think the intent here was to define "confirming entity" as an entity that
> presents an assertion for some purpose and seeks to associate itself with
> the subject and the claims. So it's not "in this case", but every case, by
> definition.

I guess I'm confused, then, because on line 2050, "presenter" is 
specially defined as distinct from "confirming entity".

>>***2.5.1.4, 970: this should say a system entity that has a SAML
>>name identifier rather than a SAML system entity
> 
> 
> Ok. Note, I think the use of SAML authority in this section should probably
> be "asserting party"...

Check.

>>***3.2.2.2, 1713: change to just system entities, instead of SAML
>>system entities?
> 
> I guess. Sort of has to be a SAML-aware entity by definition if it's 
> inventing new status codes.

Yeah, but then we have to treat "SAML system entities" as yet another 
flavor of entity that's in between generic ones and specific ones, and 
I'd rather not...  I'll change unless someone has a strong complaint.

>>***3.4.1.2, 2225: if request issuer is changed to requester, this
>>would be better as Identifies the set of prior requesters on
>>whose behalf the requester is acting
> 
> Yes.

Never mind... :)

>>core-02g-diff
>>***3.4, 2039: the explanation of what gets to be called an
>>identity provider seems too limited in scope (just authorities
>>that handle the authentication request protocol), compared to the
>>glossary definition
> 
> 
> That may be true. I intended it to be precise (because early on, a lot of TC
> members asked a lot of questions about what an IdP was supposed to encompass
> and Liberty was always less technical in defining terms like this). I also
> tried to avoid referencing the term in other places unless I meant to, and
> removed a lot of references to it.
> 
> The idea was, how can we take the somewhat informal SP/IdP notion and ground
> it in the core spec in a well-defined way.

The specific question I would raise is: Is a SAML V1.x "authentication 
authority" (which was specifically not a thing in charge of actual 
authentication on request) a SAML V2.0 "identity provider", or not? 
That's what gets left out of the specific definition you've got, but is 
perhaps implied by the current glossary definition.

	Eve
-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com