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

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

My responses below...

>SAML authority:
>core-02g-diff
>***2.6, 1070: would be better as asserting party, as it is paired
>with relying party; or the mention of a relying party could be
>removed
>***2.6.1, 1072: should match the reference on 1070

I'd agree with that change.

>***2.7.4.3, 1448-1449: would be better as asserting party, as it
>is paired with relying party

Agree.

>***3.2.2.2, 1707, 1737, 1741: says the error is on the part of
>either the responder or SAML authority; correct?

I think so, we wanted to allow for some indirection here.

>**3.4, 2036: this involves a mixture of authority, asserting
>party, and responder aspects; leave as is?

It could be changed SAML Responder, but my goal here was to draw a
comparison between the idea of an Authentication Authority responding to
queries in SAML1 and this new protocol to interact with one in a new way.

>***4.1.2, 2820-2821: should be asserting party, to stress the
>bilateral nature of version communication

Agree.

>***5, 2911-2912, 2922-2923, 2930-2931: should be asserting party,
>to match the related mentions of relying party

Agree.

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

>[other] authority:
>
>core-02g-diff
>***2.7.2, 1121, 1139, 1142: should be SAML authority or
>authentication authority?

I favor SAML authority, as the SAML statement model makes it questionable in
many contexts to precisely constrain whether a given entity is only acting
as one kind or many kinds of authorities.

>***3.7.3.2, 2715: should be session authority?

Yes.

>Issuer: generally used to describe the process of issuance
>
>***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.

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

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

>Entity: generally used for the abstract notion or to help explain
>the meaning of one of the more specific terms
>
>***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.

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

>***2.7.3.2, 1327: ditto

Ok.

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

>***3.2.2.2, 1755: OK (but would be better worded as An entity
>that has no knowledge of a particular attribute profile has been
>presented with an attribute drawn from that profile)

Agree.

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

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

-- Scott