[OGSA-AUTHZ] comments on "OGSA Attribute Exchange Profile Version 1.2"

[Tom Scavo]

On 1/10/08, Blair Dillaway <blaird at microsoft.com> wrote:
>
> A few comments and questions on this draft:

Thanks for the feedback, Blair.  Please see the comments below.

> 1)      This spec effectively says that all necessary protocols and
> encodings have already been defined by OASIS (SAMLCore, SAMLBind, SAMLX509,
> SAMLPRof).  If that's the case, and there's no substantive profiling
> required, it may be more appropriate to make this an informational document.

I tend to agree with you.

> 2)      The only 'profiling' statement seems to be a requirement that SAML
> Attributes conform to the XACML Attribute Profile. Since "Use of WS-TRUST
> and SAML to access a CVS" requires this, it is good for consistency.
> However, comments in the doc indicate some disagreement on whether this a
> requirement.

I was the one who inserted that comment in the doc and I still feel
that way.  If all we're interested in is attribute exchange (and
that's precisely what this document is about), then the desired
attribute profile (if any) is mostly irrelevant.

I think the normative statement in section 4.1 about the XACML
Attribute Profile can be removed altogether.  In that case, your
suggestion in (1) above is even more relevant.

> If it changes, I think you should justify the difference in
> the two specs.

I don't think removing the normative language regarding the XACML
Attribute Profile leads to an inconsistent family of specifications.
On the contrary, removing this restriction makes this specification
more usable in general.

> 3)      Given the reliance on [SAMLX509], it seems this spec is geared
> toward environments relying on X.509 principal authentication. If so, you
> might want to make that clear in the introduction.

The use case outlined in [SAMLX509] is pretty clear about this, but
yes, it can perhaps be mentioned in the introduction to the OGSA
Attribute Exchange Profile.

> 4)      Both this spec and "Use of WS-TRUST and SAML to access a CVS" deal
> with attribute retrieval. It would be good clarify how this spec fits into
> the model used in the other WG specs (i.e., Section 3 of the latter spec) to
> aid readers in understanding where each is intended to be used.

Yes, I agree, especially if we choose to convert this to an
informational document as you suggest.

> You may also
> want to provide a brief rationale for why the SAML protocol is appropriate
> for this spec while WS-Trust is appropriate in the latter.

I'm not sure what form this rationale would take.  What alternatives
to SAML attribute query are there?  Moreover, I don't think it's
appropriate for this spec to rationalize choices in the other spec.

> 5)      I was surprised to see no discussion of mutual authentication,
> integrity, and confidentiality. The OASIS specs do mention various ways of
> handling message security, but I don't believe they mandate any specific
> security mechanisms.

[SAMLX509] mandates mutual authentication and suggests possible ways
to achieve integrity and confidentiality.  If you have comments or
concerns about the security requirements in [SAMLX509], I encourage
you to submit your comments to OASIS while [SAMLX509] remains in its
Public Review period (through Feb 9):

http://www.oasis-open.org/archives/tc-announce/200712/msg00004.html

Also, you may want to review the proposed "SAML V2.0 Attribute Sharing
Profile for X.509 Authentication-Based Systems," which has
significantly stronger security requirements than [SAMLX509].

> Within grids, I would have thought people would want a
> message security interop profile all implementers would agree to support.

In that case, you may prefer the security requirements of the "SAML
V2.0 Attribute Sharing Profile for X.509 Authentication-Based
Systems."  I really would like to hear your reactions to that profile
(but, please, direct your comments to OASIS, not here).

I would be interested in hearing other opinions regarding the security
requirements in [SAMLX509], and whether they are adequate for  the
OGSA Attribute Exchange Profile.  If not, we have two choices: 1) send
comments to OASIS regarding [SAMLX509] and wait to see how the SSTC
responds, or 2) insert the desired security requirements in the OGSA
profile.  Of course if we add more normative language to the OGSA
profile, we won't be able to convert it to an "informational"
document, but that's okay, I guess.

Tom Scavo
NCSA