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

[Hal Lockhart <hal.lockhart@oracle.com>]

Scott,

Thanks very much for the comments.

First a general observation. The main idea of this profile is to standardize current practice. The descriptions of configurations and processing come from our knowledge of various products Oracle has acquired or those of other companies where our staff has worked. the features which are new to SAML are largely intended to meet existing requirements. We have not explored any new usecases.

> 
> Comments on wd-03:
> 
> (Please turn line numbering on in the PDF for the next drafts, makes
> review much easier.)

You are right and I am embarrassed. (I was one of the TAB members advocated PDF format in order to have stable line numbers.)

> 
> Section 1, elsewhere, should http be more formally referenced 
> as HTTP with
> appropriate reference to 2616?

Ok, will do.

> 
> Normative References: the SAML spec references need to be 
> cleaned up, or
> they'll get caught during QA by tc-admin. You can find the 
> proper syntax
> from some of the recent SAML spec drafts.

Thought I had done this, will check and fix.

> 
> Why is section 3 ultimately non-normative? Couldn't this be 
> written as a
> SAML assertion profile regarding what the content should be and what
> MUST/SHOULD/MAY be evaluated? I guess I'd find it more 
> intuitive to see 3
> and 4 combined in that manner.

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?

> 
> SAML element references should be in Courier, and namespace-qualified
> (<saml:Conditions>).

Ok, will fix.

> 
> 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.

>I assume not, but I also wonder why it would be 
> required, since
> SAML SSO doesn't always include a NameID. Also, why would we 
> make special
> note of profiling it?...use of the NameID attributes should 
> be governed by
> the NameID Format, as with any other usage.

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.

> 
> Why does subject confirmation have to be bearer? Couldn't one 
> use client
> TLS in, say, the HoK profile, and use this to create a 
> session that binds
> all the activity to the client key?

We never thought of that. Since the profile defines just two transport methods, both of which involve the use of cookies, we assumed it would be bearer.

The problem with the TLS idea is that if the browser bounces from one server to another, it will be necessary to do the TLS startup handshake on every message. This will have a dire effect on latency and could affect server capacity as well. For this reason, standard practice is once a TLS session is established, the browser is always directed to the same server (nailed up connection). In this case there is no need to distribute session information.

> 
> 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.

> 
> Sec 4.4:
> 
> Are these intended to be "basic" attribute names? I'm 
> strongly against any
> use of SAML attributes in which the NameFormat is left unspecified.
> Certainly in a formal SAML document, anyway. I would prefer we use URI
> naming if at all possible, but I'm assuming maybe you're 
> trying to save
> space. 

No, this was just oversight on my part. (I see our engineers got it right.) I will fix it.

>But I think any practical use of an assertion in a 
> cookie will be
> compressed anyway.
> 
> 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.

> 
> What's the purpose of AuthenticationStrength?

This is another codification of existing practice. It is intended to make access control simpler and stable as new authentication types are supported. Suppose the site supports passwords (20) and hardware tokens (60). Instead of rummaging around through the authentication statement, the access control rule can be "admin access requires a strength of 50 or more". Then when smartcards are added as say (75) the rule does not have to change.

> 
> Sec 5: Says the cookie name can be specified metadata, but I 
> don't see any
> profile for that here. 

An earlier draft had a complex scheme for cookie naming. I dropped it, but left section 7. I will turn section 7 into the metadata section.

>Is compression allowed? Shouldn't it be?

We didn't think of it. Frankly we were more worried about time than space. An assertion with an HMAC and no attributes runs around 2K. We know we are safe with any browser up to 4K, so you can add up to 2K of attributes. Above that you can use the reference scheme.

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?

> 
> Sec 6: Why base 64 the parameter only? That's technically not 
> part of the
> URI binding syntax you're reusing here, so I'd suggest that 
> URL-encoding
> the whole URI and leave it at that.

My bad, I got carried away with base64. URL-encoded is the way to go.

> 
> Sec 7: seems superfluous

Agreed. See above.

Hal

> 
> -- Scott
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
>