Re: [security-services] Blog post on Change Notify / comments on Aug 24 meeting

[Phil Hunt <phil.hunt@oracle.com>]

Phil
phil.hunt@oracle.com




On 2010-09-01, at 12:59 PM, Scott Cantor wrote:

>> I might not have constructed this in the best way, but
> ChangeNotifyBaseType
>> adds the operations "NewSubject", "ModifySubject", "RetireSubject" to
>> RequestAbstractType.  Then, NewSubjectType and ChangeSubjectType extend
>> ChangeNotifyBaseType to add elements/attributes needed for those
> operations.
>> The retireSubject operation currently has no parameters...though we may
>> change that.
> 
> My issue is the fact that the base type is only used in the single
> ChangeNotifyRequestType type so there's no reuse. There is no
> NewSubjectType/etc since the various operations are not in types, but as a
> choice in the base type.
> 
> Relatedly, one might argue this is reintroducing the whole "tunneled"
> approach to operations inside a common wrapper message, which we more or
> less abandoned with SAML 2 in favor of top-level elements signaling the
> operation type.

Hmmm. I was kind of following the way ManageNameIDRequest was set up. Is this not the preferred way?

> 
>> Agreed, this makes sense.  There may also be a terminology issue. For
>> example, in the "NewSubject" operation, it does not necessarily mean a
>> Subject is contained. It  currently contains just a set of attributes that
>> collectively represent an entity that will likely become a Subject in the
>> target.
> 
> Your schema did in fact use saml:Subjectt. I'm not talking terms here, I
> mean the reuse of the SAML element seems wrong when you don't want what it
> actually contains.
> 
>> Is it better to use "NewEntity"/"ChangeSubject"/"RetireEntity"?
> 
> Entity has meaning in SAML already. I thought the usual term in SAML, like a
> lot of other specs, for this was Principal.

I am open to using "NewPrincipal"/"ChangePrincipal"/"RetirePrincipal".  How do others feel?

Originally I was using subject thinking it fit better with SAML terminology. However, then it gets confusing between a SAML NameID object vs. SAML Subject object.

> 
>>> Sec 2.6, I think this answers my ChangeNotifyBaseType question...you
> have
>>> this response message layered on RequestAbstractType. Just pull the base
>>> type, and base the request and response messages directly on the proper
>> SAML types.
>> 
>> Not sure I understand. I thought that is what I was doing. Maybe you mean
> to
>> eliminate the base type and have each message type go directly on
>> RequestAbtractType? I guess I was thinking that makes the schema more
>> repetative.
> 
> You have your response type layered on top of SAML's RequestAbstractType by
> way of your common base type. That's not going to work.

D'oh!  I see what you are getting at. I'll fix that in the next update. Will change to samlp:StatusResponseType.
> 
> -- Scott
> 
>