September 2005 - ogsa-wg

Proposed agenda for Sept. 7th call
by Hiro Kishimoto 05 Sep '05

05 Sep '05

Hi all, This Monday is US Labor day and we won't have a call. The following is a proposed agenda for OGSA-WG telecon on Sept. 7th. Wednesday from 5pm to 7pm (CDT). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0907 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (August 31st) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050831/en/1 Winter F2F meeting update OGSA WSRF Basic Profile 1.0 final call Agenda bashing 2) EMS architecture discussion (90 min) Andrew and Ravi will send out detailed agenda before the call. From F2F meeting minutes: > - Agreed to define one or two scenarios and go through them to > explore interactions between the various 'pieces' > - Volunteers: Andrew, Jay, Ravi, Stuart, Mike > - Goal to present something by GGF15. But need to produce > something before that. > - Agreed to continue the work on the OGSA teleconferences. From Toshi Nakata @ GRAAP-WG > We in GRAAP feel that WS-Agreement has a very important role in the > OGSA world. (I hope you have that perspective also.) Since the newer > draft of the WS-Agrement is close to the 2nd public review, > we were wondering how we should discuss the role of WS-Agreement in > OGSA esp. in OGSA-EMS. 3) Wrap up (10 min) AOB Sept. 12 (Mon) Basic security profile, roadmap document Sept. 14 (Wed) Architecture 1.5 (Profile Definition?) Sept. 19 (Mon) Information Modeling ---- Hiro Kishimoto

1 0

OGSA WSRF Basic Profile v1.0 Final call
by Tom Maguire 03 Sep '05

03 Sep '05

A clean copy of the OGSA WSRF Basic Profile v1.0 has be uploaded to Gridforge. Please send any comments you may have on this refactored profile (removal of security sections to allow for better composition) to the mailing list. I would like to get a rough consensus on the Wednesday call 9/7. Thanks, Tom Frey’s Law: “Every 5 years the number of architecture components double and the ability to comprehend them halves” Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

1 0

Implied Abstract Name Profile
by Frank Siebenlist 02 Sep '05

02 Sep '05

I'd like to make a case for the definition of an "Implied Abstract Name" profile for ws-addressing. By claiming to adhere to this profile, the EPR-minter would indicate that care has been taken with the construction of the EPR's address to provide it enough uniqueness properties such that it can be used as a "name" by itself. The observation is that if an EPR-minter can determine that the reference refers to a uniquely identifiable resource such that an "abstract name" can be constructed, then in many cases it could also add enough uniqueness properties to the EPR's address such that the address itself could be used as an alternative abstract name. For example, if a uuid could be generated as an abstract name, then the implementation may also be able to choose to base the dispatching information in the address' URI on that same uuid, which would give the address's URI and the abstract name's URI equivalent uniqueness properties. Now, in some cases, the resource identifiable information is not present in the address value, but is somewhere embedded in the optional reference parameters. Again, the EPR-minter may have a choice to make that resource identifier information for the reference parameters just as "unique" as the equivalent abstract name it could create. In those cases, one could standardize a recipe to construct a unique "implied abstract name" from the address and the reference parameter values. For example, one could concatenate the address and the base64-blob of the canonicalized reference parameters to yield a URI-value for the implied abstract name. (Or one could concatenate the address and the digest value of that base64 blob if you care about the length of the value... at the expense of being able to reconstruct the address+reference-parameters from that implied abstract name...) In summary, if the EPR-minter is able to generate a abstract name value for a resource, then in many implementations, the EPR-minter could also generate an address (+reference parameters) that would yield an implied abstract name with the same uniqueness properties. The EPR-minter could communicate the adherence to this "Implied Abstract Name" profile by labeling the EPR somehow. The spec shows that one can add attributes to the address element: /wsa:EndpointReference/wsa:Address/@{any} such that we could label such an address element with an attribute that would tell you the profile that this address value adheres to, like implied-abstract-name="true". Tom Maguire suggested (and prefers) an approach that attachs a claim (wsi:claim) to a wsdl element (likely a port or binding). wsi:claim="http://example.org/ImpliedAbstractName There may be other (better) ways... Now... why would this be any better or worse or why do we need this at all? The abstract name as it is defined now in the ws-naming spec is part of the EPR, but does not get communicated on the wire. In other words, once the soap message is constructed from the EPR according to the ws-addressing recipe, we loose the abstract name as it doesn't get mapped into the message header content. In other words, from the header information we can not derive any unique identifier for the resource this message is meant for. In order to enforce resource specific policy on a soap message or to write traceable information in audit logs, we somehow have to obtain a unique identifier for the resource. In some cases, and certainly when we're inside of the dispatching service itself, we can assume that that application can find the mapping back to the abstract name that was issued in the EPR. However, that mapping is application specific logic and therefor not easily accessible from within the runtime where transparent policy enforcement is applied. Also, any soap-routing intermediate won't have access to the abstract name. Hopefully, these example make the case for such an "Implied Abstract Name" profile, as it would allow one to obtain a unique identifier for the resource from a message that was generated from a profile compliant EPR. Note that this profile would not make the abstract name element obsolete as for resources that change their reference over their lifetime one needs a stable resolvable name. Having both an abstract name and an implied abstract name would allow one also to keep mapping tables outside of the EPR-minting applications, which is needed to correlate policy and audit trails for the same resources. --- If the requirement for an implied abstract name and the need for an associated profile hold water, then it may be appropriate for the ws-naming wg to add such a profile definition to its charter. Regards, Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

2 1

Updated Roadmap document and Spreadsheet posted to gridforge
by Takuya Mori 01 Sep '05

01 Sep '05

Hi All, I made some updates on the roadmap document for the OGSA-Authz-WG documents as well as the standard spread sheet. The changes are: 1. to move the sections to chapter 5, because the both documents can be classified as recommended profile documents, 2. to update the title of the use of SAML document for authz, 3. to update the spread sheet fot the change of the title of the document, and, 4. someother changes of the descriptions The following is the url for them. Document Title: draft-ggf-ogsa-roadmap Document URL: /projects/ogsa-wg/document/draft-ggf-ogsa-roadmap/en/18 Document Title: ogsa-referenced-standards: Document URL: /projects/ogsa-wg/document/ogsa-referenced-standards/en/12 Thanks, Takuya

1 0

Teleconference minutes - 31 August 2005
by Andreas Savva 01 Sep '05

01 Sep '05

** NOTE: There is no call next Monday, Sep 5. ** Minutes attached. Gridforge. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050831/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 31 August 2005 ==================================== * Participants Mike Behrens (R2AD, LLC) Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Tom Maguire (IBM) Takuya Mori (NEC) Andreas Savva (Fujitsu) Jem Treadwell (HP) Jay Unger (IBM) Pete Ziu (Northrop Grumman) Minutes: Andreas Savva * Minutes of August 29 approved without changes * Dec/Jan F2F update Hiro posted a new survey yesterday. So far there were 11 responses; a couple were anonymous and will be ignored. Overall it looks like the middle of Jan is preferred at the moment. http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/08/msg00117.html * GGF15 update - Requested 2 slots - Opening is on Monday, and there are WG sessions over 4 days - Trying to arrange for the OGSA Overview session to be immediately afterwards the Opening session * OGSA WSRF BP 1.0 review - Reviewed new version posted by Tom. - Section 8: this is the security text worked on during the last call. - It allows for the definition of multiple security profiles. Also multiple claims can be attached to a wsdl:portType so multiple (security) profiles can be used. - The minimal requirement is that the OGSABasicSecurity-1.0 claim must be present. - Tom to change the name of section 8.1.1; make it fit the text - The 'wsi' namespace is not in the namespace table. Tom to add. - Should there be a reference to wsi:claim in 2.2? - Not necessary but added explanatory text on 'attachment mechanisms' to line 164. - Other changes included namespace changes; remove dates form namespace URIs. - Tom to upload a clean copy and do a final call, possibly early next week. * Roadmap 1.0 review - Tom has completed both basic security profile entries and related changes. - Takuya to do an update for the OGSA AuthZ documents and send to Jem within the day. ** Trademark usage discussion - There has been an offline discussion on OGSA trademark and service mark usage, involving Greg Newby, Hiro, Tom, Jem, Andreas. - So far agreed to put the trademark mark on first use of /OGSA/ - And add Trademarks section on the first page (under the Copyright section) - Has GGF decided to trademark the OGSA phrase as well? And what is the status of the registration? - Hiro only knows that a trademark and service mark is being acquired for /OGSA/ only - Consensus to also try and trademark the phrase as well Action: Hiro will ask GGF to trademark the phrase as well. Also to register these not just in the US but in the UK and Japan also. - Use trademark as an adjective not as a noun - E.g., 'Oreo cookies' not 'Oreos' - The problem is that for the Roadmap there are 300+ instances of /OGSA/ so it is a lot of work to try and fix everything right now. - Is it worth it at this moment, especially for an already finished document given that there are no concrete GGF guidelines that can be expected to be enforced for all GGF documents (e.g., by the GGF Editor)? - Consensus is not yet, at least not for finished documents. - Ask the GFSG for guidelines? - Yes, ask GFSG/Legal Dept. for guidelines Action: Hiro to talk to Steve Crumb again about formal guidelines. - In summary, the tentative approach agreed on the call is - First use of OGSA should have TM (or SM) - Add a Trademarks section after the Copyright section - Beyond that, 'Use OGSA as an adjective' is left up to the individual editors until there is a firm GGF guideline. - Should the BP be changed too? Yes, as described above. Action: Jem will do a final call for the Roadmap 1.0 document on the list when the document is finished. - There is a new post-v1 Roadmap tracker. It has been set up to send mail to the list on new submissions only. * Next call - No call on Monday - Wednesday is EMS call (and WS-Agreement) - Need to refine agenda for that call - Andrew will talk with Ravi and prepare an agenda for that call

1 0