March 2005 - ogsa-authz-wg

WG Last Call: Attributes used in OGSA Authorization
by Von Welch 31 May '05

31 May '05

I am putting the document "Attributes used in OGSA Authorization" into working group last call. Please send any comments to the group by January 10th. As discussed at GGF12 and since, this document has lifetimes as a MAY and there has been speculation that this should be a MUST. I have not heard strong opinion either way. If no strong opinion emerges before last call, the document will be advanced as is (MAY). The document under consideration is dated September 6th, 2004. It can be found in Grid Forge or directly at the URL below. Von Word version https://forge.gridforum.org/docman2/ViewProperties.php?group_id=119&categor…

2 3

Reminder: WG Last Call
by Von Welch 19 May '05

19 May '05

This is a reminder that WG last call for both "Attributes used in OGSA Authorization" and "Use of SAML for OGSA Authorization" ends next Monday (Jan 10th). Please see my previous messages in the archive for details: http://www-unix.gridforum.org/mail_archive/ogsa-authz/2004/12/msg00000.html http://www-unix.gridforum.org/mail_archive/ogsa-authz/2004/12/msg00001.html Von

3 6

Bounced response to Takuya from David
by Von Welch 16 Mar '05

16 Mar '05

[David, looks like you neeed to update your subscribed address - Von] - Date: Tue, 15 Mar 2005 05:56:43 +0000 From: David Chadwick <d.w.chadwick(a)kent.ac.uk> Organization: University of Kent User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) To: Takuya Mori <moritaku(a)bx.jp.nec.com> Cc: ogsa-authz(a)gridforum.org Subject: Re: [OGSA-AUTHZ] SAML AuthZ Service Document Comments Hi Takuya these are good questions. Answers below. Takuya Mori wrote: > Hi All, > > Please find my comments on the SAML AuthZ Service Document in the > below: > > 1. 5.1 Element <ExtendedAuthorizationDecisionQuery> > Request Signed Element > - How the client should behave if it gets unsigned response although > it has requested signed one? The spec says that the response SHOULD be signed. We have two choices in my opinion. Either 1. change SHOULD to MUST then it is clear that an unsigned response must be rejected as violating the protocol 2. Add a clause to the end of current paragraph along the following lines "in which case it is a local matter how the requestor deals with the response" Whilst I dont like the second option, I suggest this is what was intended by the original specification. > - Does a client has a free choice for the behavior? > ie. A client may ignore the response if it isn't signed even if > it has requested a signed response. yes correct. > > 2. 6.1.1 NameIdentifier Element > - the NameQualifier element is open for the use by applications? > IMO, it is good to make it open for application usage > Since we dont say anything about the NameQualifier element, but say "is unchanged from the SAML specification" then you have to consult the SAML spec to determine its usage. > 3. 6.1.2 SubjectConfirmation Element > - Does the confirmationMethod still be set to > http://www.gridforum.org/ogsa-authz/saml/2004/01/am/gsi? > even if the subject confirmation method contains X509 Id cert. Yes according to my reading of the spec > - How a responder (authz svc) should behave if the data of a subject > is supplied in the SubjectConfirmation Element? Is it required > to validate the data? > No. The PDP has to authenticate the requestor, and may require the subject to be the requestor, but there is no requirement to authenticate the subject. This should have already been done by the requestor. > 4. 6.1.4 Action Elements > - I think it would be better to define the string representation > more specific. The QName of the operation would be better. The only requirement is that the requestor (PEP) and responder (PDP) have a common understanding of the action name. I dont agree that a QName would be best, since the URI (the first part of a QName) is already included in the Action element namespace attribute. Thus all we require is the local string name for the operation. > > Hope it isn't late, No, I have made edits to the spec in accordance with the above regards David > Takuya Mori > > ---- > Takuya Mori > > -- ***************************************************************** PLEASE NOTE NEW CONTACT DETAILS AS OF 1 JAN 2005 David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NZ Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick(a)kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************

1 0

GGF13 schedule (important changes!)
by Olle Mulmo 10 Mar '05

10 Mar '05

All, There were some unfortunate clashes in the schedules for the security area sessions. Therefore, the CAOPS#1 meeting HAS MOVED to Tuesday. There's an additional clash between CAOPS#2 and the ad-hoc delegation BOF, but nothing could be done about that. We will see if summaries of those sessions can be prepared and presented at the Security area meeting, which follows directly after. Various security related sessions that may be of interest: Monday, March 14: 1pm-2:30pm OGSA-AuthZ, Sapphire 3 5pm-6:30pm Firewall Issues Group BOF, Emerald 1&2 Tuesday, March 15 1pm-2:30pm Town Hall meeting, Crystal 3pm-4:30pm CAOPS#1, Onyx 5pm-6:30pm WS Delegation ADHOC BOF, Sapphire 1 5pm-6:30pm CAOPS#2, Crystal 3 7pm-8:30pm Security Area meeting, Sapphire 2 Wednesday, March 16 11am-12:30pm Grid VPN-RG BOF, Crystal 3 Not yet scheduled: Trusted Computing BOF See you in Seoul, /Olle

1 0