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