4. Section 2.2 bullet 8. We should
discuss, for the federation case, when the user is required to log
into the SP. I.e., this can be before the IDP login or after. Are we saying it's
up to the SP or does it always have to be after the IDP login.
[bobc] We can discuss this
further on the call to see what people agree
5. End of section 2.2. You added a
possible requriement of displaying the xml documents that were exchanged. Do
users really want to see this? Also, what are you thoughts on how this is
presented (e.g., thru an external screen/log, or on the actual user browser
was a carryover from last year and is up to each vendor if or how they display
this. It is basically a trace log to lend some credence to what is
6. Section 3.1 first sentence. You
say four, but I think you mean three (i.e., login, logout, and eAuth). I think
that breakdown works the best. I think you should move section 4.2 after the
logout discussion so it will be section 4.2. Then change sections 4.3 and 4.4
into 4.2.1 and 4.2.2. Basically following the same format/structure you defined
in the summary section 3.1.
[bobc] I actually meant SP initiated login, idP initiated
login, SP initiated logout and idP initiated logout as the 4 base
SAML cases, and then eAuth as a separate 5th case. I'll have a look
at the section setups when I update it next
7. Section 3.1.3, item 2b. s/on the
SP is/on the SP and is/
[bobc] WIll change
8. General comment on the optional
use case. I beleive the SP should state which name id format it is requesting,
i.e., x509 subj name or a persistent id. This is done via the NameIDPolicy
element. This implies that the SP site, which lists the IDPs that support
persistent identifiers, needs to be smart enough to distinguish between the 2
types of identifiers when calling and IDP. We had said this would be based on
the user name. However, if the answer to (4) above is that the user logs into
the IDP before the SP, then the SP does not know who the user is and therefore
cannot be sure which NameIDPolicy to use. I'm proposing the SP has additional
smarts in it (each vendor does this however they want) so that the IDP links on
the SP site hare two-fold. There are links for the base case IDPs and links for
the optional IDPs. Additionally, the eAuth use case always implies the base case
IDPs, hence x509 Ssubject names. Section 6, item 1, wording would be
[bobc] I was heading in that direction myself on the last
call when people said they could just figure things out from the user
name. Let's discuss this some more on the call today since I think your
method will simplify things for the demo
9. Section 3.2, item 4 and 5. I
don't believe this requirement was mentioned on any call/email. I.e., obtaining
user consent is up to each individual provider. I suppose these could be
optional steps but they should not be required. I.e., when a user clicks on
the IDP link at the SP, they are consentng to federation. The same goes for
section 6 bullet 4.
[bobc] I think it was mentioned in passing when
discussing this case and was never explicitly called out. I know this was
a big deal in the Liberty Alliance specs. Let's discuss on the
Section 3.2, item 8. s/SP triggering/SP via the IDP triggering/ The idea
being the user does another saml login at the IDP by initiating it at the SP
(basically a repeat of your item 1). To me it seemed like the text in
item 8 is suggesting that perhaps the user logs in at the SP.
[bobc] That is more accurate
and will be
11. Section 3.2, item 9. s/on the
web page/on the SP web page/
[bobc] I will change
12. Section 4.1.2, item 3. s/of
links to the SP resources/of SP resources/ ^ s//(URLs)/ The text suggest
the links (actual URLs) are to the SP site when they are actually urls back to
the IDP with some TARGET=xxx or RelayState=xxx query parameter.
[bobc] I will change
13. Section 4.1.2, item 4.
s/resource links and/resources and/
[bobc] I will change
14. Section 4.2 (a
question for Enspier). It's not clear to me how the eAuth site knows which IDP
the user has selected. Are they using persistent cookie? I.e., I'm asking
this to understand what can or cannot be done at the SP. I.e,. if we do the
eAuth use case for a couple of SPs and then do the logout. Then a new user tries
the demo, how does the eAuth portal know this is a new request (i.e., the
user is no longer logged on to the intial IDP)? It would seem that the link back
to the eAuth site would require a CCID=<idp entity id> parameter much like
the one that is sent to the SP. Section 4.2.2 mentions using cookies to
avoid propagation (but I don't think this will work).
[bobc] Moved up for
16. Section 5.1 item 1b. The Saml spec requires subject confirmation
data, s/MUST NOT/MUST/ and the data should include recipient,
notOnOrAfter, etc..... In general I think you can remove section 3. This
is just a restatement of what is mandatory in the saml spec. I.e., similar
to saying you need to include an IssuerName, etc....
[bobc] Some carryover from
last year's doc. I'll take it out if people find it
17. Along the lines of S3ction 5.2.1 item 1, an AuthnRequest should
either not inlcude an RequestedAuthnContext element or should value this
[bobc] Anyone else have feedback on this one?
It is a carryover as
18. Section 5.2.1, item 2
and section 7.1, item 3. Why are there any restrictions at all on
SubjectLocality? Shouldn't this just be up to the IDP.
[bobc] I gather this
was added last year because people had some problems with DNSName.
Anyone else have feedback on this
19. Section 5.2.2, item
1. Is everyone ok, with the 3 attributes. It seems like using postal
address (someone else suggested this attribute at a prior meeting) would add to
the personalization features of the demo.
[bobc] Anyone else have
feedback on this?
20. Section 8.1.1, bullet 1 and 3 AND section 8.1.2 bullet 2.
I thought we agreed that there would be one SP resource for each SP and each
vendor would only have one IDP. So change the zero or more reference to
there is one of these per vendor. Anything beyond one would complicate the eAuth
site, the links necessary on each SP/IDP, etc...
[bobc] Not every vendor is
required to provide both an SP and an idP. As I recall, someone
mentioned that last year not all vendors provided both. That is why the
zero. I will change the "more" to
Section 8.1.1, bullet 3. s/URL to the idp logon page/The SAML entity id of
the IDP/ The entity id format is like a url but it is NOT a url and is not
meant to be the idp login url.
[bobc] I was using the recommendation in the spec, especially
since we are only using front channel bindings. I was trying to make
it simple, but can change it if it is not accurate for
22. Section 8.1.2
bullet 3. Actually remove the IDP entity id reference from 8.1.1 and move it
here, note that this is a URL but an entity id
Section 8.1.2 bullet 1. For issuer name, is this a string for display
believe that is how it was used last
Section 8.1.4. I would say copy the list of vendors into A.2 as well. I.e.,
store the value for <Vendor> in the appendix so it's easy to retrieve.
Also, in A.2 perhaps store the following data point: IDP-Basic, SP-Basic,
IDP-Optional, SP-Optional to indicate which vendor is doing what. It would be
really helpful to nail this down before the dry run.
[bobc] I plan to add that in
somehow once I have who is supporting
Section 8.1.4, I would suggest sticking with the same password convention as the
base case. I.e., the password is the same as the userid. It just makes things
easier I think.
[bobc] Or should we make just one password that
is the same for all users for both base and optional? Anyone
else have feedback on
Section 9.2.2 bullet 5 s/qill/will/
[bobc] I will fix
27. Section A.2
and 8.1.1. The additional URLs that are necesary (in A.2 and in 8.1.1)
SingleSignOnService (at IDP for base and optional
AssertionConsumerService (at SP for base and
SingleLogoutService (request) (at IDP and SP for
base and optional case)
(response) (at IDP and SP for base and optional
- ManageNameIDService (request)
(at IDP and SP for optional case
ManageNameIDService (response) (at IDP and SP
for optional case only)
[bobc] Will expand those
28. Section A.2
and 8.1.2. The additional identifiers that are necessary (in A.2 and in 8.1.2)
SP entity id (simliar to idp entity
Receiver Name (similar to the idp issuer name). I.e., a display name for the
[bobc] Will add
receiver name. SP entity id is same question as