Minutes of OGSA Basic Profile Meeting April 6th, 2005 ===================================================== Present: Tom Maguire, Frank Siebenlist, Abdeslem Djaoui, Ian Foster, Takuya Mori, Jem Treadwell, Latha Srinivasan, Sam Meder Notes: Jem Treadwell Minutes of March 30th call: Abdeslem mentioned that his name was spelled incorrectly (to put it mildly!); minutes accepted with that correction. Initial discussion ================== Tom quickly reviewed status, and noted that: - Tom to ask Andreas to close 1298. - Revision 4 of the Basic Profile document has been posted (2005-040-06). Discussion of Tracker 1321: ========================== See notes posted by Takuya: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/04/msg00031.html Takuya introduced the proposal, which defines a key info type to exchange Key information with an endpoint. Example shows how the endpoint key info will be expressed. Tom: Question about the options. Takuya: We've defined 2 use cases - (1) key is used for encryption, (2) key used for authenticated identity, which should be used for authorization. Tom: I discussed the proposal with IBM's WebSphere security guys, and they were talking about using a security policy as opposed to carrying security data in the metadata for the endpoint. What are the interoperability characteristics? If I place this info in here I must understand it or I won't be able to message with the endpoint. This is intended for interoperability, so what are the MUST requirements?... Abdeslem: MUST UNDERSTAND is a requirement on the service. Frank: Must pull the data out of the EPR, and use it to encrypt... Tom: not merely an echo - e.g. need for non-repudiation. Is it OK for us to have metadata that's required to be understood as part of an interaction? Frank: Did the WebSphere developers suggest an alternative? Tom: No, don't have one. Are there alternatives to embedding it in the EPR? It would be required for the interaction, right? Agree that it needs to be done at a container level. Globus/Univa folks would need to work with this. Sam: Right now that code doesn't provide any security support, but will think about when we think about migrating to apache etc. Tom: OK, need to think about need for MUST UNDERSTAND metadata - also usually alternative mechanisms for getting this, so are we presuming an optimization of another exchange mechanism that will be available - e.g. this metadata is a cached view for optimization - it's not authoritative because it could be stale. Frank: If there's a standardized way to do this we should jump on it... Tom: I'm fine with that; don't have a problem with this, and I like the reuse. Frank: So does IBM have an issue with implementing this? Tom: I don't think WebSphere will implement unless I argue for it; they would implement the spec they have authored. Frank: So if we put a MUST they won't be OGSA B/P conformant? Tom: Think that's true. Frank: Any other instances? Tom: Hasn't been any other MUST in the B/P that would preclude WebSphere being conformant. Tom: Moving back to using Globus Toolkit container, rather than putting it into WebSphere; programming model differences between GT and WebSphere are significant. Tom - is the metadata the authoritative data or not? General view that it isn't - it's a cached copy - so placing normative requirements on understanding it (is) interesting ground, and I'm not sure where we're heading. Frank: agree that there are many ways that data could be obtained, but we have to agree on at least one to communicate securely... Tom: Happy to put it into the profile and have the discussion about whether it should be a SHOULD or a MUST, etc. No argument about it technically. Frank: fine; just want to make sure we have some agreement. Takuya continued review of the example... Tom: How do we integrate it with profile... just schema, so have to define it somewhere normatively, and will need to put MUST/SHOULD requirements somewhere - do we make this an appendix showing how this stuff works? ACTION: Tom will fold into Basic Profile as an appendix, and see how it looks and feels, and add a short section in the B/P main text to reference it. ACTION (Tom): Next call: Need an agenda item to discuss this, and then carry the message back to engineers for feedback. Other Trackers: =============== 1322: Use of Proxy certs - Dave Snelling's issue; Dave not on call. Frank: should also have Dane Skow on the call for this. ACTION: Tom to send a note to ask Dane to attend the next meeting for discussion. 1323: Frank: Haven't finished internal discussions to propose a solution for this. Working on a proposal for attribute assertions. Status: Pending. Basic Profile Document ====================== 1211: Dave Snelling not on call to discuss. 1314: Tom has this as pending; no need to discuss. Tracker for Section 3.12: need a tracker: policy extensibility element, needs to be a metadata extensibility element; also going to update WS-Addressing to latest last-call document in this section. 1355: Issues that Dave Snelling wants to discuss. Trackers that relate to should get folded into 1355, in response to WS-Addressing last call. 3.13 and 3.14 should be removed; close 1229 and 1230. Carry on discussion re metadata in 1255. 4.2.1: Tom will consider proper wording - issue with applying conjoined requirements to a single conformance target. Problem with making things testable, so in general it's a good idea to avoid this type of requirement. R0432: Should be a SHOULD; Tom to fix. Latha proposed some changes; Tom will fix. Tom asked that everybody please review the document, and open trackers as needed to report issues. Tom could use a hand with a couple of sections; will send some questions to the mailing list for review. We need to be in a position by 4/20 to say that all trackers are reflected in the spec, and that we're comfortable - don't want any issues left that we're not in a position to discuss.