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] Blog post on Change Notify / comments on Aug 24 meeting


> 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.

> 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.

> > 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.

-- Scott




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