Days late and dollars short, comments on "entity" terminology

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

I finally carved out a few hours to review the specs on their usage of 
all the various entity-related terms.  I started with the core spec, 
which of course took the most time, and only got through that and part 
of the bindings spec.  I will continue to do this analysis tonight if 
folks think it's not entirely too late to sneak in a few more editorial 
changes tomorrow!

In the attached file, only the lines starting with *** are the ones 
where I thought a change was warranted.  Overall, the usage looked 
pretty good, and it helped me sharpen up my understanding of when to use 
each term (perhaps my summaries can be useful in the Tech Overview or 
similar).  I made a few other non-entity-related recommendations along 
the way, some typos and some "heavier".

	Eve
-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com
In citations below, the section number is followed by the one or
more specific line numbers.

Asserting party: generally paired with relying party

core-02g-diff
2.2, 418: OK
2.2.2, 467: OK
2.5.1, 892-893: OK
2.5.1.6, 1030-1032, 1036, 1039: OK

bindings-02f-diff
N/A


SAML authority: generally used to refer solely to the assertion
issuer, or to discuss trustworthiness/authoritativeness of the
issuer or its assertions, or to describe how to use metadata
provided by the issuer

core-02g-diff
2, 356: OK
2.3.1, 572: OK
2.3.3, 597: OK
2.5.1.1, 918: OK
2.5.1.4, 965, 974, 976: OK
2.5.1.5, 999, 1017: OK
2.5.1.5, 1049: OK
***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
2.7.2, 1106: OK
2.7.3, 1227: OK
2.7.4, 1339, 1344, 1374, 1379: OK
2.7.4.1, 1404, 1405: OK
2.7.4.3, 1437: OK
***2.7.4.3, 1448-1449: would be better as asserting party, as it
is paired with relying party
***3.2.2.2, 1707, 1737, 1741: says the error is on the part of
either the responder or SAML authority; correct?
3.3.2.2, 1843: OK
3.3.2.4, 1929: OK
3.3.2.5, 1968, 1970: OK
3.3.4, 2008: OK
3.3.4, 2027: OK
**3.4, 2036: this involves a mixture of authority, asserting
party, and responder aspects; leave as is?
3.4, 2039: OK
***4.1.2, 2820-2821: should be asserting party, to stress the
bilateral nature of version communication
***5, 2911-2912, 2922-2923, 2930-2931: should be asserting party,
to match the related mentions of relying party
8.1.2, 3289: OK
***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?

bindings-02f-diff
3.7.5, 1400: OK
3.7.5.1, 1405


[other] authority:

core-02g-diff
***2.7.2, 1121, 1139, 1142: should be SAML authority or
authentication authority?
3.3.2.2, 1832: OK
3.7, 2563, 2565, 2568, 2570, 2573, 2576, 2577, 2580, 2676: OK
(session authority)
3.7.3.1, 2642: OK
3.7.3.2, 2668 ff.: OK
***3.7.3.2, 2715: should be session authority?

bindings-02f-diff
3.2.3.5, 392: OK
3.7.5.1, 1409: OK


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?
2.2.5, 559-560: OK
***2.3.3, 597: OK (though I question the usefulness of the SHOULD
here)
2.3.3, 603, 632, 636, 641: OK
2.5.1.5, 1006: OK
2.7.2.2, 1196: OK
***3.4 and subsections: should request issuer be simply
requester, for simplicity and consonance with our protocol
terminology? note that it appears very frequently!
3.5.3, 2454, 2456, 2457, 2459: OK (artifact issuer)
8.3.6, 3365: OK
8.3.7, 3382: OK
8.4.x, 3422, 3425, 3429, 3435, 3439, 3442: OK

bindings-02f-diff
3.6.2, 1024: OK
3.6.4, 1064, 1066, 1074, 1076, 1079: OK
3.6.4.2, 1094, 1099, 1102: OK
3.6.5, 1113: OK
3.6.5.2, 1169, 1177, 1182: OK
3.6.6, 1195: OK


Entity: generally used for the abstract notion or to help explain
the meaning of one of the more specific terms

1, 227, 228: OK
1.3.2, 310: OK
1.3.3, 316: OK
1.3.4, 326: OK
2.2, 407, 411, 414, 415: OK
2.2.2, 446, 470, 473: OK
2.2.4, 540, 541: OK
2.3.3, 599: OK
2.3.4, 678, 679: OK
2.4.1, 709-712: OK
2.4.1.1, 742: OK
***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.?
2.4.1.2, 777, 782, 786: OK
***2.5.1.4, 970: this should say a system entity that has a SAML
name identifier rather than a SAML system entity
***2.7.3.2, 1327: ditto
2.7.4, 1353: OK
3.2.1, 1555: OK
3.2.2, 1632: OK
***3.2.2.2, 1713: change to just system entities, instead of SAML
system entities?
***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)
3.4, 2044-2064: OK
3.4.1, 2088: OK
***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
3.4.1.2, 2227: OK
3.4.1.4, 2310: OK
3.4.1.5, 2321: OK
3.5.3, 2453: OK
3.7.3.2, 2699: OK
3.8, 2717: OK
5, 2930, 2932: OK
8.3.6, 3361-3370: OK
8.3.7, 3383, 3385: OK

bindings-02f-diff
3.2.2.1, 308-309: OK
3.3.3.1, 489: OK
3.4.3, 549: OK
3.4.5, 622-624: OK
3.5.3, 782: OK
3.5.5, 816-818: OK
@@1033: STOPPED

Identity provider

core-02g-diff
(I didn't check exhaustively)
***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


Other typos noticed along the way:

core-02g-diff
***2.2.2, 474: Section needs to be capitalized
***3.4, 2037: need space after period