GGF13 OGSA-WG session #2: Basic Profile (1 of 2) =============================================== * GFSG request/proposal Hiro introduced a GFSG proposal that applies to all OGSA design teams. No answer was expected in this session. (Decision postponed for the next day to give people time to think it over.) - OGSA design teams work well with low overhead and fairly restricted scope. But changing scope, increased work load (especially for team leaders) and the desire to improve visibility of the teams (and thereby increase the number of people working on them) leads to the proposal to allow an easy/low-overhead path to promote design teams to full WGs. E.g., no BoF, just submit an application. - GFSG questions (to design team leaders) - Is WG promotion beneficial or not? - Which teams want to be promoted this way? - Any obstacles or problems - Any new WGs created this way should be aligned to OGSA-WG (since they'll be defining profiles) * Tracker resolution process Tom described how the tracker is set up and in particular the proposed artifact states. These are modeled along the lines of other WGs or TCs but may not be identical (explanation is also available on the tracker page) The intention is that all submitted artifacts should be closed before the document can be submitted. Artifacts can be submitted through the gridforge ogsa site or via the mailing list (if they are clearly label as issues someone will put them in the tracker). * Referenced specifications - There is a well known inconsistency between the base notification and resource lifetime specifications. The specs are using different versions of the ws-addressing specification. Tom and Dave are following up on this issue with the TCs. - What is the difference between WS-Security and WS-I BSP? There are some additional requirements. Issue: Check whether there is a need for a normative reference or not and how it is used; delete otherwise. - Not all WSRF specs are referenced. Are they all needed or not? Some are missing and should be added; in particular the Base Faults specification should be referenced. Also need to check whether the WS-Resource specification should be added to the references. Other specs are probably not needed. For example, the ServiceGroup specification is not needed since the profile has no statements about it. - It has been stated that OGSA does not mandate WSRF. But if OGSA mandates the BP then it would effectively mandate WSRF. Agreed that this is something that needs more discussion. But it should be discussed in a session that is publicized in advance; to give the opportunity for interested parties to join the discussion. Agreed to schedule the last 30 minutes of the next session to talk about this issue. Send an email to the OGSA WG mailing list after this session (done). * Security discussion - Frank's and Takuya's presentation on security - A side discussion on the effect of additional grid requirements on the underlying tooling. In particular, whether vendor (tooling) support is essential before a feature or solution should be added to a profile. Two positions were put forward: 1. Profiles should not attempt to describe 'solutions' of grid requirements that cannot be easily supported by current tooling. This group should wait until tooling catches up and only use whatever is available at the moment. 2. Profiles should describe solutions to grid requirements even if these solutions are not widely adopted by tooling vendors. Waiting for vendors may take a long time; doing nothing does not seem reasonable. From experience (Frank) vendors do not seem to recognize grid requirements as important to them, at least not yet. There was further discussion on what specifications exist in this area and a suggestion to use kerberos (rfc1510) more in the profiles. It is widely adopted. - Scope of the proposed security profile: communication channel security, authentication. - Issue: Check status of WS-I BSP 1.0 and when it is expected. - It was re-stated that normative statements in specs referenced by an OGSA profile CANNOT be relaxed; they can be strengthened however. - But strengthening a statement might still cause problems with tooling. - The critical issue is whether the requirement is correct or not - But even if the requirement is right if the tooling support is not there .... - It was suggested that the statements being made in the profile should not cause the problems that the meta-level discusion seems to be assuming. In any case, the profile statements are concrete and should be reviewed one by one rather than having this kind of meta-level discussion that does not seem possible of reaching a conclusion satisfying to anyone. - WS-I SAML token profile: Might have to build something similar to this in order to support assertion communication as discussed in the presentation. - Embedding in saml token? Frank/Takuya are still looking into the specific rendering possibilities. ** Other issues - Transport/message to be added to issues for BP - Discovery of key-info for message level security (not an issue for transport(ssl) since it is part of that standard). - Use of proxy-certificates - There are a number of issues with such time-boxed credentials; need to pick these apart before making a decision on whether to include it or not. - (There is no problem on-the-wire but validation logic is needed at the end and that is not part of normal tooling.) - It was suggested that for real deployments kerberos is more important than either proxy-certs or PKI. - Consider including kerberos in the security profile - Communication of assertions * General review of tracker artifacts ** 1316 - Need to synchronize with WS-Addressing as that specification moves to a more stable draft - If there is a separate naming profile that the BP would depend on it. More discussion is need on how to take care of this dependency and in particular the release timing. - The only assertions left in the BP are those of structural conformance of EPRs. ** resource property for creation timestamp - Sounds like a reasonable idea, but the problem is that not all service might have one; perhaps this is optional. (no decision) ** QueryRP issue: Even if this is made optional the xpath requirement could still remain. [Continued in the next BP session.]