Markus Lorch wrote:

Von and others,

I was originally hoping that we may have obligations defined in this version but have been convinced by the arguments presented by others on the list that we should go ahead and finalize the May version without the addition on new features first.

One note on the Advice extension point (5.1.1 Element < AuthorizationAdvice>):

When coding additional advice types that utilize this extension points I noticed that, at least in the existing prototype implementation within GT3.3, it requires changes to the low layer parser for the ExtendedAuthorizationDecisionQuery.

I think this is due to the fact that AuthoizationAdvice is an abstract type for which instantiations of AuthorizationAdvice change the tag name to e.g. SubjectAttributeReferenceAdvice and this tag name thus has to be recognized directly by the parser that reads the ExtendedAuthorizationDecisionQuery.

I think if you write the schema properly, the parser will recognize that SubjectAttributeReferenceAdvice extends AuthorizationAdvice, and therefore is allowed instead of the latter. I am not sure what the situation is with the schema used by ExtendedAuthorizationDecisionQuery. Sassa

Would it be a more scalable/extensible approach to have an base-Element called "AuthorizationAdvice" with a minimal general structure which could be extended by specific Advice implementations without chaning the Element tag name within the ExtendedAuthorizationDecisionQuery. This would allow a parser for ExtendedAuthorizationDecisionQuery to parse through the query without having been armed with all the code that would anticipate every single possible advice implementation. I.e., adding one more level of redirection to facilitate that somebody who wants to extend by adding a new advice doesn't have to modify the parser for ExtendedAuthorizationDecisionQuery.

It may well be possible that it could be coded this way with the existing definition but I just don't know how. I will be happy to learn about the appropiate way of implementing such an extension point.

Markus

...

-----Original Message----- From: owner-ogsa-authz@ggf.org [mailto:owner-ogsa-authz@ggf.org] On Behalf Of Von Welch Sent: Dienstag, 14. Dezember 2004 19:41 To: ogsa-authz@gridforum.org Subject: [OGSA-AUTHZ] WG Last Call: Use of SAML for OGSA Authorization

I am putting the document "Use of SAML for OGSA Authorization" into working group last call. Please send any comments to the group list by January 10th.

As discussed at GGF12, I have taken the May 14th version (prior to the Obligations work) made the changes indicated at the end of the email. The resulting document is dated December 14th and can be found in Grid Forge, or directly using the URL appended below.

I understand that at least one group member wanted to get Obligations into this document, but I believe this document captures a vital snapshot of implementations in its own right and should be move forward. It can be followed by another version with Obligations. Those feeling strongly about this are encouraged to indicated to the working group as part of the Last Call process.

I expect to follow this with a Last Call on the Attributes document shortly.

Von

Word version: https://forge.gridforum.org/docman2/ViewProperties.php?group_i

d=119&category_id=450&document_content_id=3227

PDF version: https://forge.gridforum.org/docman2/ViewProperties.php?group_id=119&category _id=450&document_content_id=3228

Changes from May, 2004 to December, 2004 version:

* Added Appendix C giving an example of how GT4 creates URIs from WS-Addressing elements.

* Marked Recipient field in 5.1 as depreciated since it is insufficient to stop replay attacks.