RE: [security-services] Groups - saml-session-token-v1.0-wd03.pdfuploaded

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

> My thinking was that it would be hard to get agreement on the processing
> steps. I decided to simply say what fields were required and what their
> semantics are. Even if it was normative, most of the steps would be optional.
> Suppose instead of changing section 3 I add wording to sections 5 & 6 to
> make the reading and writing steps more explicit?

I'd probably need to see a specific proposal, but I guess I'm just saying that I'd like to see the specific assertion profile be explicit for interoperability.

> > Section 4: does this NameID have a connection to a NameID in
> > a SAML SSO context?
> 
> I am probably missing some subtle point, but I did think they were the same.
> If the session started with an IDP authenticating the user and generating a
> SAML assertion with an authentication statement, then I assume the
> NameID in the session token would be the same and the entire
> authentication statement would be copied into the session token.

Ok, the problem there is that the NameID isn't required during SSO.

> I guess I could eliminate the requirement. In the environments this is
> targeted at the NameID, whether long term or pseudonymous, is used as a
> lookup key to find other attributes for access control. It also may be used by
> the application in various ways.

What I'd probably expect, I suppose, is creating a new format, perhaps, or using a transient, and using the session key as the NameID.

> > Are Conditions allowed, or just times? If not, we should say that.
> 
> I assumed anything defined by SAML which is not mentioned may optionally
> be used. I can say so explicitly.

It comes back to the assertion profile, I just want it to be clear.

> > Why is SessionStart needed if it's guaranteed to match
> > AuthnInstant anyway?
> 
> Originally, I allowed any number of authentication statements and defined
> session start as being the most recent. It was decided to change this to say
> that there is just one authentication statement. I left SessionStart in thinking
> I might get some push back on this definition. I am still inclined to leave it as a
> hedge against the future.

I guess I just figure smaller is better.

> There doesn't seems to be any standard for cookie compression. Surely you
> weren't thinking of EXI? I don't think that would drive adoption. Do you have
> something specific in mind?

Just DEFLATE or whatever, nothing unusual.

-- Scott