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

> Scott, some minor comments on these as you move this into 
> Public Review form.


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