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: RE: [security-services] Comments on SAML 2.0 Core draft-19...


> First off, unless they are formatted incorrectly, I would say that
> the condistions are always *valid* (as in a correct condition).  The
> issue is that the valid condition is not *met*.
> 
> I consider the validity check to involve multiple steps including:
> 
>     a) Basic Schema validation
>     b) conditions are met
>     c) Signature validation
> 
> All in all, I don't think this is a biggie.

The whole terminology aspect again predates anything I was involved in, so I
don't really feel that strongly about it, but it will take some effort to
try and adjust the way we talk about conditions.

>  > I watered it down on purpose. It says to me nothing more than "you can
>  > create a new identifier". There's no implication beyond that that I
>  > can see.
> 
> The problem is that for many of us it isn't "you can create a new
> identifier" but rather a positive statment of "I want you to create a
> new identifier".  The difference is subtle but signficant.  We want
> the SP to clearly indicate that they are initiating a new identifier
> creation as opposed to having it look like the default is to do so.

I agree about the default (I think false is better), but I think that's
separate from distinguishing "create a new one" from "you may create a new
one". In SAML, I wanted it to be the latter, because the range of
identifiers and semantics is much more varied.

> So, I would rather see the attribute called "PleaseCreate" or
> "CreateNew" with the default to being "false".  While technically
> there isn't a big difference in the specs, this will have impacts
> in privacy group discussions.

IIRC, in ID-FF, when the SP said "federate", it allowed for the possibility
that such an identifier already existed. So even there, I think it was more
"this is what you can do if needed" vs. "this is what you must do at this
point in time".

> In the case where the Identifier already exists (i.e. it is a global
> identifier) the IdP would not need to create a new one.

Global != already exists. By global, I meant not a privacy-preserving value
restricted to a namespace based on the relying party. Concrete
example...maybe my SP deals only with X.500 names. I can say "I want an
X.500 DN, and if you don't already have one established for the principal
but, you may create one to give to me if your policy allows."

>  From the looks of the rest of the schema, we did not make something
> an attribute or an element based upon the centrality of it to the
> action taking place.  And I don't think it should be.  Attributes
> aren't a second class component in XML.

No, but there's a subjective basis for choosing between them that comes up
from time to time. But it is subjective.

> Sorry.  No good excuse other than I just didn't get around to it.

I guess the main issue is, how do we work through/decide the issues quickly?
Most of them I agree with...we need quick discussion/agreement on the call,
I guess.

-- Scott



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