> 1. Do we have any other examples where we might have a SAML > requester/responder other than the case of the RP/IdP? If so, it might be > wise to mention at least one other case in the introductory paragraph in > section 1. Otherwise it might be easier to just say that we are sending > messages between the RP and the IdP and not generalize it. Can anybody > see a reason that one might want to reverse the endpoints? So that the RP > becomes the server and the IdP the client???
Any binding should be left generically defined as SAML requester and responder, even if you don't specifically have a use case to hand. It's just the right layering. But aside from that, I can at least point to some protocols that could be useful and would reverse the flows. NameID mgmt, ID mapping, and the Oracle Change-Notify proposal would all be possible flows that reverse the roles. But whether that's possible in ABFAB I don't know. > 8. In section 5.4.1 paragraph 3 - I am not sure how this section interacts > with the ability of an IdP to return a Pseudonymous identifier. Are you > stating that the identifier must already exist, or just that the policy for > creating the identifier must already exist in the case AllowCreate is set to > "false". That text is probably somewhat ill-advised. It most likely got copied from the original browser SSO profile, and I never wanted it there either. It's repeating SAML core rules, and I don't like repeating spec language. But to answer your question, for more ill-advised reasons, there's a flag in SAML with a very poor default that's used to specifically limit the IdP from manufacturing an identifier for a user if the identifier doesn't already exist. If AllowCreate is false, the IdP is supposed to fail rather than mint new state between itself and the SP. -- Scott _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
