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] Stateless Conformity To SAML

> Many of us consuming companies are working hard toward centralized
> identity management and therefore much prefer the "cause to be stored"
> approach over the "stored" approach.  Also, many of us are very
> concervative when it comes to what mechanisms we will allow to write to
> our "stores".  So I see us being cautious about turning on NameIDMapping
> functionality (although I expect we will see applicable scenarios as our
> deployment expands).

NameID Mapping or NameID Mgmt? I assume you mean the latter. NameID Mapping
is a read operation. NameID Mgmt is always a write to something/somewhere.

> So, if as Scott suggests as a deployer I have the option to negociate
> NameIDMapping out-of-band, and as the Core spec allows I can return a
> status of InvalidNameIDPolicy I can see this working for us.  

I think we're talking about different stuff here. But yeah, as a deployer
you don't have to support any feature in the spec unless you're partnering
with somebody that expects you to. That's a contract thing, not a
conformance thing.

> For those "cause to be stored" implementations, I see a bit vague
> separation of duty between the implementor responsibilities and deployer
> responsibilities.  Also, how a functional NameIDMapping actually works
> on the backend in the "cause to be stored" environment may vary
> substantially.  Seems an implementor needs to allow for the "stubbed
> out" NameIDMapping function, but at the same time I don't think we want
> to declare an implementation that is nothing more than a stub out
> (always returning an InvalidNameIDPolicy) to be declared conformant.

No, that wasn't really my point, but it probably amounts to the same thing.
I'm saying I might drop in a dummy implementation via a database that nobody
could/would use for production to implement the write operations, and I
could pass a conformance test. But I'd much rather say "I support this
profile *if* you provide an implementation of my plugin interface to
implement the persistent write operations into your account data". That's a
more honest statement and a lot more useful to you.

> Gee...so what exactly does the conformant implementor have to do in a
> "cause to be stored" solution when I won't let him/her write to my
> store?  Suppose I just turn it off and the implementation always returns
> invalid.  Appears in the "cause to be stored" environment the real
> functionality in NameIDMapping is outside of the spec.

Again, NameID Mgmt, but yes. It is outside the spec. How could it be
otherwise? We're talking about changing account names used by applications
to do any of a million things, stored in potentially any number of ways.

-- Scott

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