Next in thread → Next in month →

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

From
Thomas Wisniewski <>
Date
2006-03-15T16:11:04+00:00
ID
Thread
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:] 

> 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

>
Next in thread → Next in month →