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] Saml Metadata Extension for Query Requesters Spec


Title: RE: [security-services] Saml Metadata Extension for Query Requesters Spec

Scott, I'm fine with the way you've structured it -- perhaps others may have different (strong) opinions/suggestions. Most of these comments were observations/comparisons to what's in metadata already.

Thanks for the clarification on the attribute qualifier.

Tom.

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Tuesday, March 14, 2006 8:22 PM
> To: 'Thomas Wisniewski'; 'SAML'
> Subject: RE: [security-services] Saml Metadata Extension for
> Query Requesters Spec
>
>
> > Scott, some minor comments on these as you move this into
> > Public Review form.
>
> Thanks.
>
> > - line 147: PDP requesters
>
> This is worth discussing in the context of your later note
> that we should be
> consistent. I hadn't seen us refer to authz queries as "PDP"
> queries or even
> "PEP" queries, or I would have used that language.
>
> I don't feel strongly either way. Slight preference for consistency of
> "Query" language across the three types even though it's
> PDPDescriptor, but
> others should weigh in.
>
> > - line 167: I believe you're missing the ActionNamespace
> > element definition as anyURI.
>
> It's up above, first line. We can move it below if you like. ;-)
>
> > - line 79, you abstracted out the query requester items, but
> > this was not done for the authorities. I believe this is
> > correct, but was wondering if staying consistent with the
> > current metadata scheme makes sense.
>
> I don't recall the original motivation in the base schema.
> Sometimes things
> look different when you come back to it later, looking back I
> probably would
> have done a base type there.
>
> I don't use the kind of tools that care much what the "types"
> are, but if
> people would prefer a shallower hierarchy, we can change that.
>
> > - line 145, along the same lines as above, authz decision
> > authority was called "PDPDescriptor" and not
> > "AuthzDecisionAuthorityDescriptor", I believe your proposal
> > of AuthzDecisionQueryDescriptor is correct, but for
> > consistency, did you consider "PEPDescriptor"?
>
> No, I didn't. I originally didn't use PDPDescriptor, but went
> with that when
> people asked for it. I hadn't seen any similar term applied
> to the request
> side. I don't care much either way.
>
> > - ine 83, is it just typical that for attributes, we define
> > new ones within the schema (query namespace) as opposed to
> > use the one from metadata. Specically I'm looking at the
> > query:WantAssertionsSigned attribute vs. md:WantAssertionsSigned.
>
> I think you're confused here. Attributes in general are not
> namespace-qualified when they're defined inside an element's
> type. That's
> true of the Want flags across both the original metadata
> schema and this
> extension draft.
>
> If you're adding an extension attribute later to an existing
> element with a
> wildcard option, then you typically define the attribute in a
> new namespace,
> and that's done by declaring the attribute at the top level
> of the schema.
> An example of that is the third-party request draft, and the metadata
> extension flag defined there.
>
> By default "local" attributes (defined inside element types) are
> unqualified, thus have no namespace.
>
> -- Scott
>



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