OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Comments on XSPA profile

Section 1:

On the call I suggested that this could use more explanatory text as to the
nature of the profile being presented, because SAML is so varied. I think
the bulk, if not all, of this profile is about Attributes.

In that vein, I would also add more to the Non-Goals section to clarify what
isn't covered, namely protocols for acquiring or delivering assertions.

Section 3:

One reason I found identifying the scope of the profile confusing was the
broad language here. I don't think it's fair to say this profile "provides
access control..." if all it's concerned with is formalizing attribute
usage. Without the protocols and the rest of the assertion content, it's
really a very small piece of that picture.

Section 3.1:

It's slightly confusing to present all these interactions when the profile
doesn't really describe them. I think I would collapse a lot of this into
the introductory section that just motivates the material, rather than
including it in the formal section 3 that defines the profile.

Section 3.1.3:

I think we need to be careful using the word "Attributes". If the intent
here is that these are SAML attributes, it should probably say so. I think
it's meant more abstractly here, in which case I would make that clearer.

Sections 3.2/3/4/5:

I'm not sure that any of this is worth including. In particular, it seems to
be out of scope, and it's not reading as normative. 3.4 also seems
questionable since SAML 2.0 doesn't define anything called "error states",
and to the extent that it deals with errors at all, it's at the protocol
level (which I don't think you're intending to use).

Section 3.6:

I think you're trying to say that you're not constraining confirmation
methods, but if so, why include it at all? More importantly, the rest of the
text is inaccurately referencing material that is not related to SAML
confirmation methods in any direct way.

Since I think without the protocol context, it's impossible to really say
anything about the non-statement content of the assertion (e.g. subject
confirmation, conditions, signing), I would suggest just avoiding it or
ruling it out of scope in the way I suggested earlier.

Section 3.7:

The title and the sentence don't really go together. Use of metadata doesn't
seem to be in scope of this profile (again, no protocols), and use of
AttributeStatements isn't really a "metadata definition".

I think what you're trying to say is that the assertions are intended to
carry only AttributeStatements? Frankly, I'm not sure that's wise.

Section 3.8:

Naming Syntax, Restrictions and Acceptable Values...of what?

Section 3.9/10/11:

This frankly to me is what the profile is trying to be, and should probably
be the whole of section 3. In that event, I would suggest structuring the
document as an attribute profile in the fashion of the SAML profiles that
were done. The bases are mostly covered here.

Section 3.10:

Are you trying to constrain equality of attribute names, or values?

Section 3.11:

Avoid the word namespace here, it does not have any meaning in this context.
I think you're trying to say that you want to define a URN prefix to use for
your attribute names. That's about the only technical term I could think of
for what you mean by namespace.

In your examples, the XML is incorrect with regard to the xsi:type
attribute, which is not a URL, but a QName (e.g. xs:string). I think XACML
uses URLs, but XML Schema doesn't.

The remainder of this section I think is defining actual Attribute "types"
(in LDAP parlance). We have a couple of profiles that do that in SAML, I
think, so that format could be emulated.

Additional comments:

OASIS requires profiles to have a conformance section now, which we've been
putting at the beginning of the doc. The document is also missing some
required boilerplate, and the references need some clean up to align with
our usual conventions there.

-- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]