[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]