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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services-comment message

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


Subject: RE: [security-services-comment] PR comments on SAML V2.0 Identity Assurance Profiles, Version 1.0


> Line 33: no namespace. Line number 123 say "defines a restricted version
of
> the AuthnContext schema". Would it not make sense to put this in its own
> namespace to avoid confusion with the original? There is usually some
> mechanism used to be able to identify when a profile is being used.

The schema at line 123 is (and probably should be more clearly noted as) a
template for how to create actual schemas bound to actual LOA-driven context
classes. It's not an actual normative schema itself (which is why there's no
such artifact in the document tree).

Because the document does not actually define real LOA frameworks, it
doesn't include actual context class schemas.

> Line 171: "When these words are not capitalized, they are meant in their
> natural-language sense." This is in violation of RFC2119. Use other words
> in non-normative text.

That phrase has been in every SAML document back to 1.0, and I see nothing
in 2119 that implies this is a "violation". It's not a long RFC, but maybe I
missed it.

> Line 207 thru 210: This template has no introduction or description, so I
> have no idea what it is saying.

I agree, I think it needs overview text.

> Line 211, section 2.2. There is no normative requirement in this section.
Is
> this intentional?

Yes, there's nothing being defined here other than an example of how to
apply a mechanism from SAML to the LOA problem.

Arguably, it might be better not to assign a profile URI to this entire
section, but to present it more informally. It's a tricky problem.

> Line 340: this is the ONLY normative MUST I see in the whole document
> (excluding the conformance section). I think there is more going on in
this
> spec than a single MUST, but I can't figure that out.

There actually isn't. Figuring out how to explain that is not simple.

> Line 389: implementations of what? Please clarify.

I actually think (as I said above) it's not quite a profile and that the
conformance requirement here is merely duplicating SAML core anyway.

> Final comment. There needs to be some more tying together of  sections 2,
3
> and 4 so it is obvious that they are defining something that is a coherent
> profile.

I agree. I don't know how to do it though. It's a set of conventions of
existing material to do something that concretely has to be defined
elsewhere.

-- Scott




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