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

Yes, my mistake - mgmt not mapping.  I was looking for the return status
to the mgmt request to indicate "unwilling" and wound up in the mapping
section inadvertently.  So, is the status for "unwilling to write ID
change" still InvalidNameIDPolicy, or is it something more meaningful I
did not find?


-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Friday, July 30, 2004 2:32 PM
To: Beach, Michael C
Cc: 'SAML'
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

> 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

No, that wasn't really my point, but it probably amounts to the same
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]