RE: [security-services] Blog post on Change Notify / comments on Aug 24 meeting

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

Some general comments on sstc-saml2-notify-protocol-01b, ignoring some of
the basic editorial issues, incorrect hyperlinks, etc. If you could, please
try and go through the document and clean up the formatting of any XML
element names using the Courier font, so we don't have to do this later in
an editorial pass.

Also, you need to define the XML namespace here, add it to the table in sec
1.1, add samlp to that set, and properly qualify the elements in the text.

Line numbers are from PDF.

There are lot of references to the earlier proposals. I suggest removing
them and making this a stand alone proposal, and if you want the back
references, use a change log appendix at the end for that.

Sec 1.2, I suggest qualifying these terms as "notification issuer and
target" to avoid collision with existing notion of Issuer in SAML. Also
rephrase SAML service entity to SAML entity.

Sec 1.3/1.4, seems like a lot of these references are unneeded, such as
5280, 3820 and the XML security specs. Also the reference to delegation
conditions is pointing to a CD instead of the CS.

Line 212, I would change multi-protocol to "protocol agnostic". We're not
saying you have to use more than one.

Line 214, suggest wording as "In typical SAML scenarios, user information is
propagated through the use of the Browser SSO Profile [SAML2Prof] and
similar profile variants..." Also suggest softening the sentence with "there
is no means..." to point out that the IdP can notify the SP of NameID
changes and either party can notify the other of deprovisioning, but that
other changes aren't addressed. It seems to be incorrect about what you can
do, for example saying that an IdP can't inform an SP of defederation, which
is just wrong. I would avoid words like "core profiles", that's not a
defined concept.

I would also avoid terms like "web service providers", that's just too vague
and suggests notions of SOAP and such, or assumes HTTP is the application
protocol, which SAML does not assume. I think you just mean service
providers.

Lines 243-244, this is already by definition in SAML, doesn't need to stated
here.

Line 250, I think you want to relax this to "any supported profile of the
Authentication Request protocol", rather than assuming Browser SSO.

Line 291, s/expires/Expires

General schema questions, why is ChangeNotifyBaseType necessary? Can the
message just be defined as one type extension of RequestAbstractType?

Also, should the *Subject elements carry a Subject or a
NameID/EncryptedID/BaseID choice directly? Subject implies an optional
choice of those elements plus optional SubjectConfirmation. So if the
SubjectConfirmation isn't involved (which seems likely here), all you should
need is the identifier, not a full Subject.

Sec 2.6, I think this answers my ChangeNotifyBaseType question...you have
this response message layered on RequestAbstractType. Just pull the base
type, and base the request and response messages directly on the proper SAML
types.

Sec 2.7, I suggest swapping this with 2.8, the examples should be at the
end.

Sec 2.7.1, I suggest replacing Tom Scavo's UIUC identity, since he's not
with UIUC anymore. Just use a dummy identity. Also, I think your OID for
mail is off, but I must confess that it's probably a matter of opinion,
sadly. FWIW, the one we use in eduPerson is 0.9.2342.19200300.100.1.3

Line 461, it says "the default falls to the Issuer node". I can't parse
that, but even so, it then says the target does the initiating, so that text
seems off.

Sec 2.8:

I think you need to separate any of this front vs back channel discussion to
a formal protocol profile (which you need anyway). The base protocol rules
should be presented in a binding agnostic fashion, and then you can have a
profile section that has normative language based on the binding. The SAML
profiles doc uses the terms synchronous and asynchronous in place of back
and front. I see section 4, but that seems to be about profiles of existing
profiles in conjunction with this new one, not just a profile of the new
protocol. I think you want a cleaner separation of the rules here.

Line 499, why is LDAP issuer initiated only? Couldn't the issuer have an
LDAP for the target to query?

Line 511, it sounds like you want actionAfter to be omitted, so just say
MUST NOT include it.

Sec 4.1: Ok, I really just don't understand the point of this. What does
adding this round trip achieve? Why wouldn't you just do SSO like now? I'm
missing something obvious...

To the extent that it's needed, I think you want to avoid duplicating all
this SSO profile material here. You should just compose it by saying "the
protocol exchange is followed by the use of any profile of the SAML
Authentication Request protocol...".

> As for yesterday's TC call, my apologies for arriving just as the call
> ended. I agree with Thinh. We need to review section 2.7.2.  Can the
normal
> web sso profile handle the requirement mentioned in the front-channel
> example?

I think I need more help with the use case the example is trying to address
to answer that. As it's described in the fuzzy diagram, I just don't get it.
This isn't how federation normally works. You don't decide what to call the
user at the SP by asking the SP, you just assign an identifier, supply it
via SSO and the SP links that to its own ID if it wants to. Why would you
*not* just do this? What's the use case?

> 1. Initial negotiation of identifiers - per the NSN requirements

I'm still trying to understand them.
 
> 2. Triggering a specific set of attributes to be transferred the first
time
> a user federates. Example, the IDP believes this to be potentially the
first
> time the user has accessed the relying party and is indicating a potential
> "new user".

Ok. It knows that independently of this new protocol proposal, so...

> There are cases where the attribute flow for first time
> federation is different than normal SSO attribute flow. [btw. the fact
that
> the attribute flow changes during initial sign on isn't necessarily an
> optimal approach in my opinion, I just note that the use case has been
> arising]

That's fine, but I don't see how it relates to all this work.

-- Scott