October 2006 - ogsa-wg - lists.ogf.org

OGSA design teams and members
by Hiro Kishimoto 05 Oct '06

05 Oct '06

Hi all, I setup OGSA design team wiki page: design teams and members, not only for security design team but all. It is draft status. Please have a look. https://forge.gridforum.org/sf/go/wiki1618?nav=1 > AI-0925a: Hiro to setup wiki page with names of people who have > expressed interest in the security team If you find any mistake or you want to add your name, please update this page by yourself or send an email to me. I will ask each design team lead to fill in their "current scope" and "milestones and schedule." Thanks, -- Hiro Kishimoto

1 0

secure channel profile explanatory ciphersuite statements
by Andreas Savva 05 Oct '06

05 Oct '06

The Security Profile - Secure Channel (Sep 28 draft) has a set of statements, which elaborate on the compliance statements, along the lines of "Ciphersuites listed in Table 3 in TLS-Guideline [TLS Guidelines] meet criteria of R0XXX." We discussed these statements last Thursday and it was stated that such statements are not intended to be normative. I took an action to rewrite the text to make it clearer that these are not normative statements. The problem I have after looking at the text again (incl the compliance statements) and also looking at the WS-I BSP is that it does not help people wishing to implement the Secure Channel profile if these statements are not normative and if they do not describe concretely which suites should be used (or not). Saying 'do not use known insecure suites' or 'only use secure ones' are motherhood statements. In any case they are not really testable which is one point of compliance statements. Also the WS-I BSP has some discussion and normative statements in sec.3.2 about TLS/SSL ciphersuites and since the Secure Channel states that it "extends the WS-I Basic Security Profile 1.0" I became unsure about the relation of the various compliance statements in the Secure Channel and the statements in the WS-I BSP is. In short, sorry, can't do. I am not a security person... ;-) Maybe we should discuss this issue again on the next call this Thursday. (Dave? Alan? Takuya? Frank!) Andreas

3 3

Updated: OGSA Teleconference
by Andreas Savva 04 Oct '06

04 Oct '06

BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 11.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VEVENT ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:ogsa-wg@ogf.org ORGANIZER:MAILTO:andreas.savva@jp.fujitsu.com DTSTART:20061005T133000Z DTEND:20061005T153000Z TRANSP:OPAQUE SEQUENCE:1 UID:040000008200E00074C5B7101A82E00800000000C06829BECBE7C6010000000000000000100 000001D94CC1AEEC74D49AD628FD7F700343E DTSTAMP:20061004T090532Z DESCRIPTION:When: 2006年10月5日木曜日 22:30 to 2006年10月6日金曜日 0:30 (GMT+09:00) 大阪、札幌、東京.\n\n*~*~*~*~*~*~*~*~*~*\n\n<pre>\n\nThe following is a proposed agenda for OGSA-WG telecon on Oct. 5th\nThursday from 8:30am - 10:30am (CDT).\n\nDial-in numbers for Thursday:\n Free: +1-888-452-0308\n Intl/Toll: +1-484-644-0505\n PIN: 71815\n See more information:\n - https://forge.gridforum.org/sf/go/wiki1477?nav=1\n\nScreen share service will be provided.\n URL: http://ogsa.glance.net\n Session key: 1005\n See more explanation:\n https://forge.gridforum.org/sf/go/wiki1584?nav=1\n\n1) Early discussion (20 min)\n Note taker assignment\n Roll call\n Telecon minutes approval (Sept. 28)\n - https://forge.gridforum.org/sf/go/doc13912?nav=1\n Action Items status review (see the bottom of this email)\n Agenda bashing\n\n2) OGSA security (David Snelling\, 60 min)\n - What needs to be done to achieve simple interop\n generally and to bootstrap more\n - Profile to get authentication information from a\n secure channel for authentication\n - Profile for other methods to get authentication\n informatin for authorization\n\n3) Secure Channel Security Profile status (Takuya Mori\, 20 min)\n\n> Takuya will prepare a new version. Since there are a number of\n> unresolved issues the Secure Channel will not go to final call until\n> the issues raised during this review are closed.\n> \n> There is a security discussion scheduled for next Thursday (Oct\n> 5). Confirm status at that time.\n\n4) Wrap up (10 min)\n AOB\n\n<*NEXT CALL*>\nhttps://forge.gridforum.org/sf/go/wiki1477?nav=1\n\nOct. 9 (Mon): EGA reference model\, OGSA roadmap\nOct. 12 (Thu): <No call?>\nOct. 16 (Mon): DMTF Workregister\nOct. 19 (Thu): Information/data modeling\,\n Security\, secure channel profile review\nOct. 23 (Mon): EGA reference model\, OGSA roadmap\nOct. 26 (Thu): Information/data modeling\nOct. 30 (Mon): <TBD>\n\n<*ACTION ITEMS*>\nhttps://forge.gridforum.org/sf/go/wiki1569?nav=1\n\n > From Sept. 28 call.\n\n AI-0928a: Takuya will issue a final call on BSP-Core on the list.\n AI-0928b: Takuya will get another opinion on TLS 1.1 and\n ciphersuites (probably ask Frank Siebenlist)\n AI-0928c: Andreas will propose new text for the reference to the\n NIST document to make it clearer that it is an informative\n statement\n\n > From Sept. 25 call.\n AI-0925a: Hiro to setup wiki page with names of people who have\n expressed interest in the security team\n AI-0925b: Jem to pull definitions together and produce a new\n merged first draft.\n - Send a mail to the ogsa list about this work\n - Set Oct. 9 as the target for the first Glossary draft\n AI-0925c: Hiro to ask Alan Clark to ask EGA TC member who want to\n contribute to join the OGSA list and this convergence work. -\n Members may have changed but organizations have not\n AI-0925g: Tom will send a note to the list (to: Ellen S and Fred M)\n on why the current separation of service/info model may\n not be quite right.\n\n > From Sept. 21 call.\n AI-0921b: Security members to discuss the BoF proposal(s) further\n - For example\, one outcome could be some standards\n activity to mirror CAOPS activities and tie-in to OGSA\n AI-0921d: Dave S to collect additional material in order to identify\n security issues better.\n - (AI-0921e is an issue instance)\n AI-0921i: Dave S to provide an agenda for the next security call.\n - Draft agenda items for Oct. 5th:\n - What needs to be done to achieve simple interop\n generally and to bootstrap more\n - Profile to get authentication information from a\n secure channel for authentication\n - Profile for other methods to get authentication\n informatin for authorization\n\n > From Sept. 15 OGSA F2F\n AI-0915a: (A Savva\, S McGough): Set up a telephone conference to\n collect workflow (BPEL) experience\n AI-0915b: Ellen to check the status of the items on the\n DMTF work register: report which have been done\, and what\n DMTF is doing for the rest. (by Oct. 13)\n AI-0915c: Ellen to propose new text to update the DMTF register\n (by Oct. 13)\n AI-0915d: Tom will post BP base faults issue to tracker\n AI-0915e: Hiro to talk with OGF Editor to start an errata process\n\n > From Sept. 14 OGSA F2F\n AI-0914f (Fred Brisard and Hiro Kishimoto): Fix the location of the\n next F2F and inform the group vial the mailing list\n\n > From Aug. 17 call\n AI-0817a: Dave Berry and Jay Unger will approach groups (GIN\,\n Globus\, etc) that have implemented practical grids and\n start a discussion on how they handle data:\n - how data is treated as a resource that can be scheduled\n - how transfers are modeled\n - how files are advertised\n - how applications find files (query\, by knowledge\,?)\n (Due Oct. 9)\n\n > From Aug. 3 call\n AI-0803e: Jun will provide an example of the CDL mechanism and why\n using ID/IDREF is not a good idea.\n AI-0803f: Jun will update the CDL document to remove the Environment\n variables\n\n > From July 20 F2F\n- EGR-WG (Ravi) will contact Geoffrey Fox and invites him to\n contribute use cases.\n- Andreas to go through the minutes and formulate a reply mail to\n Geoffrey on each artifact covered in these minutes.\n\nPostponed:\nUntil next EMS call.\n AI-0914a (Andreas Savva): Integrate the simple Data scenario just\n presented into the scenarios document\n AI-0913a: Andreas to update function names of BES.\n AI-0913b: Andrew to write-up a couple of such JM functionalities\n (short paragraph for each\, e.g. time constraint as JSDL\n extension.)\n AI-0913c: Andreas to add another scenario to use this “terminate”\n method of activity interface.\n AI-0913e: Andreas to separate un-deployment as a separate scenario.\n AI-0913f: Andreas to describe relation between ACS and CDDLM.\n AI-0913g: Donal to provide his proposal on\n "ActivityExecutionCandidate."\n AI-0831e: (A Savva) Talk to ACS working group for refining this\n scenario.\n AI-0831f: (A Savvva) Research RNS and probably update the EMS Arch\n Scenarios document\n\n AI-0921c: Dave S (as Standards VP) to talk to the next\n Security AD (when one is selected) about the Security Area\n task list.\n\n</pre>\n\n\n SUMMARY:Updated: OGSA Teleconference PRIORITY:5 X-MICROSOFT-CDO-IMPORTANCE:1 CLASS:PUBLIC END:VEVENT END:VCALENDAR

1 0

OGSA Roadmap draft 4 on GridForge
by Christopher Jordan 04 Oct '06

04 Oct '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've uploaded the most recent OGSA Roadmap draft to GridForge, and am passing the pen to Andreas Savva so that he can add the "OGSA-EMS Architecture Scenarios" section, and update the JSDL information, since I'm mostly still waiting on updates from document authors for most of my remaining changes. I've updated some of the document status information and done most of the formatting and textual changes required to conform to the new OGF document template. I've also added a draft Web Services context section from Mike Behrens, currently in "Appendix B". The document remains imperfect and all the graphs still need updating, but it's getting closer. https://forge.gridforum.org/sf/go/doc13733?nav=1 Andreas - Please upload the document to GridForge and let me know when you've completed your changes and are ready to pass me back the pen. Feel free to call in to the Editors discussion tomorrow afternoon if you have any comments or updates for the Roadmap document. Thanks. Chris Jordan Data Reliability Manager San Diego Supercomputer Center ctjordan(a)sdsc.edu 858.534.8347 "If we had a keen vision and feeling of all ordinary human life, it would be like hearing the grass grow and the squirrel's heart beat, and we should die of that roar which lies on the other side of silence." - George Eliot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFIzDSPCVtcXn6kg8RAjlaAKCxit0Mu95fh3ONMyO74q//BOuy8ACghdks 1GKCvJ4k+BklmJbEiVQGTjQ= =3M4M -----END PGP SIGNATURE-----

2 1

XQuery
by Michel Drescher 02 Oct '06

02 Oct '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, here's the example. Cheers, Michel - -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFIZpUk0lMZTNKw4QRAhCVAKCvVAMQQlbPbAQT6Rbh3TFjOZ2zQwCgqOZ7 lOFLThj9uYHgjYe7ZgubuGs= =CkQ3 -----END PGP SIGNATURE----- declare function local:filterByProcessorArchitecture( $proc as element(), $resources as element()+ ) as element()+ { if ( count($proc/Architecture) > 0 ) then for $resource in $resources where data($proc/Architecture) = data($resource//Architecture) return $resource else $resources }; declare function local:filterByOSType( $os as element(), $resources as element()+ ) as element()+ { if ( count($os/OSType) > 0 ) then for $resource in $resources where data($os/OSType) = data($resource//OSType) return $resource else $resources }; let $job := doc('./job_1.xml') (: load job 1 :) let $jreq := $job//Capabilities (:take the Capabilities :) let $prov := doc('./provisions.xml') (: load the hosts :) let $resources := $prov//Resource let $result := local:filterByProcessorArchitecture($jreq/Processor, $resources ) let $result2 := local:filterByOSType( $jreq/OS, $result ) return $result2

1 0

Regrets
by Maguire_Tom＠emc.com 02 Oct '06

02 Oct '06

0 *H÷ 010 +0 *H÷ $Content-Type: multipart/mixed; boundary="----=_NextPart_000_0075_01C6E644.4F15C830" X-MS-TNEF-Correlator: 50D422D665E6C601 This is a multi-part message in MIME format. ------=_NextPart_000_0075_01C6E644.4F15C830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tom _______________________________________________ Tom Maguire Senior Technologist, Office of CTO EMC2 maguire_tom(a)emc.com +1(845) 729-4806 ------=_NextPart_000_0075_01C6E644.4F15C830 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IjAVAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgBAFQAAHwAAAAsAHw4BABIAAgH4DwEAAAAQAAAAGTFs0enA QU+TG+xdGMv50gIB+g8BAAAAEAAAAEcAeBfHkKxKr+8LploFF7ADAP4PBQAAAAMADTT9PwUAAwAP NP0/BQACARQ0AQAAABAAAABUlKHAKX8QG6WHCAArKiUXHgD6PwEAAAANAAAATWFndWlyZSwgVG9t AAAAAAsABIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAADANAwARgAggBgAAAAAAwAAAAAAAAEYA AAAAAYUAAAAAAABAABOACCAGAAAAAADAAAAAAAAARgAAAABghQAAAAjW6CkAAAALABCACCAGAAAA AADAAAAAAAAARgAAAAADhQAAAAAyNQsABoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAE9SAwAD gAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAGqACCAGAAAAAADAAAAAAAAARgAAAAAYhQAA AAAAAAsAcIAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAC4wAgEJEAEAAABkEgAAYBIAAOEpAABM WkZ1byBLeAcABgEBC2BuZzEwMmY1AGQAcmNwDdAOADIdDGBjDUQBNAExc3Rz4mgFcGJjaBA1CQAQ x2ZoDrAQ1mJpAUMNpDPyMxLmZmUTYgH3AqQDY0cCABDACsBzZXQC0XAocnEyAAAqCqFuby0WICAN 8BdxNhNwMDWcMDQX8QHQF+A0fQdt3RbCZgdABUAHbX0CgwBQ9wPUFc8W22IXsRggF4IeVIcYoAcT GbdoZWx2HIDlDrBhGzQzNxuvHL8dx1cX5B4yGKBWBJBkAHBhxwKDDwIVbTIzOCIUGj74IENFGb8a yw4AE5AlfvcYECafJ6V5CLEoTylbDhC5FW0xNhuRK48DgkcJ0dZrLQ8pPTYvHzYlUTBvfQOCVAhw Mg8pPSDxErBkdmkDNi+INyDxNW8DgijISGViCXB3KTbvKT3/JoE5HzokJo87lgcQAaAOsOs8fyku OT8PODQBQF8Dgn5CQnEOsEIvKTwXwEQ/NtcqIUWPO8NWCJB0JMAHgf5lQh9IPiVRISwmaAcTJ/r/ H/1JECohTt0rR1BVLOlRb/8vASEsMBhQVDG8VU80AVaO/zU2UFQ2ullPOOhWjTp3UFT/PA9dLz6I Xt5P3EGvYc9EId9WjUVHUFRG3WZuNwvCVp3vSmZgVUv/ak9mNSBOryZo/yR1J/FvhVJ/Kzhxpyzg b4X/Vl8wGHGmMbNvhVpfNRhxpv82sW+FZ39FOHGmRtRvhBfgf3tfSldxpm2aAoACkQjmO/UJbzCC D2Uu4YM6LuKEH/+FKIMkLuKDr4d/hz2Gv4Tv84M/FDAyOI0KjiGN347p/4MkjxKNf5FPkQ2Qj46/ koT+OQ8gldSXMY9TlzACghBQvHlsB5Af8CHgAABxAyEebBLBBRABQAPwZGN0LmwKsZoQQcBwAQFh dXtNAABgcwqwmnAhoJtybkx1bUzRmzB0bw1RauZ1EFAFEGdom2AFEAoBy5mgCgFpAZBwMAMwACCm bBDAIXFzMQMwYQEx/5+AC/ArUAdADbWZgZ1AnvT/npGf0xMnE+gI0AnAPsCh0xxucKIpo8QDMHNu Zf54IfAHsAWwAMACcxbgnzF/npENYD7QIEAgIKTxIdBtTmkSAKawCfAgRJsUIBpQCsBhCcCa4Ggg RncCIaXkEGAxAFAQYANgdycLMJ1AAYBzVz7AdGjeQhOQnUAKsKawbA3gQCB9q1Ryq8gNkKs2AYCt N2LlrTdyqzJjYgqwMACvIn8iIK+DAmALgAmRsFSYsHDuZasxBPAgAGyaIasAqqH9sLFzICAAIEzx qbE8MKxQf7MWCVCzNAyxs0OaoLM0ZL5ntBa1kLUWnwCzNHYDMP+Zb5p/m4+cn52vnr+fwryx/6Dd vAENtKHEFCKf8aMsv8f/wUSk9angpyylhE0gAaCY0P+l56Chpqi87b48uWAI0CUg/aTxYrmgCYAC IKZimKEhwJs+wJ/wM0Uwj6AgSLFB77QAC4B386YjNsVPxl/Hav/I4shvyXepILHQqkAJgMoP/zpg yz+fFwBRvf8bdAwBzf/3p0oQQMohcwIgUIEQQAWgbG1wFzLJDkUAwAMQU9+YsjpggTMW4AtgdAnw EGAzmLO3sHNkEFAHcGF4b8UgNADbMRFRawmAAQEwi6XzgiB2AlEge1XKcPkXIHdu2fXJQt1S3nMm YD40XiHJQ1pARUHJQjg0/DUxK1DJQuDA4LA1IclD70kQDvATkOGkNw8QAFDJQv4zKhDgwOI040Bn YFZByUL+NA3gDfDgNN9wAdAPEeUVzDc5RCDkYzg4yaDkRPsXwBfAOeREAcDJoEUw58VuOEAQt+Hn 4jPi0OZFOO/gwEVA35SXMDABwOp2LvD/5ZUN4OjB5KDg5AHQ4hHg1f/q4cmg4jQO8OdhKhHstGtw /6vQ35TuAA7wlyDslemBa2Df69UmcBfg5tDvpTnjQA7w/+DlSlDmsO4V41HnoOA0xSDYOTQ34XX0 cTgu8OZU+zAQE3A08lD1pcmQ4LD1le9AEI+gIOH3NDkYEPSw9+b/5CDJwODk+FDJweDV6tEXsP/u FeQgXiD0Bvkh8jHfBBfw//Ph/FfmQPHF4tCrwWdh/fT/8lD2MOLkb+AX4uA06CHq8Pv3BSZgN/Sg 4KDfBMmUAab/6QAABuCg4VHg1DjB42EAFf/useTA4jUAsDAgBUdeIP2B/98E4JATgOhVj6DmQOmA 4DT/F+DmQPSQ5ETm4eCQezEJNP8wIPJACdUX4eYw35QTgFZA/99wCFXJkMmQ5CDi9OYRC7H/4vQB UOCgn/ENtelxC1XisP/iEQ8WSlBWQOGEJnBFQO62/yZw8lLoZBggycCXIuRkF8D/ezDflAmwALDg oBOX+3HkRf/3ofPh5FQYIAmBEhUYIDAg/+F1DhD0sCOh5QUu8Ogx5QX/9sABdt9x8ZHlpuCS5lXo EP8JsASFDtLwAeZl//Au4hy1/zjQ6iDmZUAQ9gASFfBAWkD/9VAe5ueg1OHJQv/wHeH0oP8gZfbA RBAhFveB8EUlQGdg/+lw4DQFENTgCAAilemA5tD/DkUFEPSQj6AilevAJTHiNP8z8PYw6vDmVDjQ +dFiwSBz/+bQokA6cSf0IjHtRSjxG3H/5EREEF4gcQAnFeZAojDnpf8wIObQM/DhhHshEcHgNPbA /2/g9JDg1PbAI/EURSbB7gD/a3HnIx3S8QVWQBNRKgVaQP9rYAmw4jQGkXaQ+FAxpftR/+hV+TED cjMlDHDmIecU+FD/55BxEefTojDuAOrwNWUIAP/mwefEOmAMcPKFIzHlgee1/+SgK3E4VuKwMvYB UAtA93D/6RUesXViOrSp4Jcw6GXpAP/JkTbV6QBnYAvgPCWksEUw/+e1J6H5Nh6R+3HmVGRg8lD/ q9A9leZA6XABUOBE6vELQP/pFPwh6YDrFcnA5MDisOI0/xKRq9Dm9SehKIAnBSei9VD/QVXyQBfx QtUi8TgR4EQwcf9BN1ZAEELgROgQlyAAsOBE/+kA+SFEVf5xGjbmwPhACvH/4ETyUPhAHUUIAf/g 98X4Uf/2weDUTRKiQE4X6XD0BfhQ//bA9tHqhKngZ1HhhPBAWjH/AYUvEV+x6GTwQOpRLcWXMP8O EDmB6oX2wO5wThUcUSt2/wjxYsAIAOqE5DDuABRFQfH/+GAABTpRCwLqhCqBB1Hr5f+iMAFQdqHr 9PARJTFaNuCR/+OFPhNv0lsWJ4HoZKBx65H/56WgcShhDkW/ovVBXwf/8P+/suv0UlFrYmDF1ODh 8WC2/09hAYWksekA43aksAmwCZH/Y+fjQFLx6+Um »sT1R6+YLIv9eNuCRY4Hg5GeCDhDslaSw//SQ dqBeNangGrHvhvARC8D/4CVQwRKRDYWp4AvAT2Foxv9NMfV3xSAL4EK2qeDngf8B/26GH3EYxW7R 8/EMBang9LH/LxFoBT1BCLFxxnmB9JBxxv8+AeZFc7IXAF72c8E9cV1l/yPRj6BdVmrhIjHtVuDA C0D/IQVaozaR7KUjAW/34pKrwv95Jeog+cF6tyiAWuZVUWLx/+vVVVFK0XxGFwEgsX32CZD/eBgb cQxwfrbgsDFh7JYR8f8m0YBm56BXkYIH6OBw1uHx/wxwCbDuJhzxWhYE8fGS7ub//9EJkO7mayAI AO1WPIHz9/+IESiA7RCHtx6Ch7ZbkXQW/+jR32F8RvVQTcFhdTXx/+D/LcXv8emh7gZSUfJASYXv 8f8oQT2F7/HyUY+3RkHgoe+l/+Cw/NKRdioABnGRdikxWUb/40CDYXJ2ZUGAwu+l+sDz8f+MhmFg 9KBzRl7RkTGSNugQ//MRlKZNslBF8jH0wN9h8eb/9LBWNvIxNEHyh+eRZhHg5f92IqSwnNb1cVKF nSH7UeyG/8mQiQGdhwCB5rDyllbxZjf/9tHqUaGnDACksPQVAsF/8f+hphPxG6GkJmsg9KDvlQ4Q //nCWVVnsQJA5DXhMh3ho0b/mhE1Aag3Cafy8eSgpXHypv9EMfrGqwIngfKmg1FjBqWR/28Aomf0 kB6hnMbnoPdxnzb/56CmYaaG5CDxsWF1//BTAv/vlf/wKoEFRZHx5NBQwbLG/wOBgeaR4QUx81b+ MDLCtTb/C8HzRyMB/aG1NjaRZkbrwP/rgRpFxSB0wo1GuaF0sbeW/+SgCzG6B4JhW7YYkfhBsRb/ A5FGMfNlDUH+MLeWMrESwP++F1YxcAaTghKRwJYWQXMQ/8CWryGZdgmQW3HCF3ZxBdH/9CYs8e7G OBHnoKWm5WEIsf9clfrAflFbtuQwLNHHxxBx//YQ9BVwwQIhyXea4eZA0RMweG1sbtrA3tF9XHRw YdCRd3lhnLHMI2jHCYJhcNlAcmdsciHNhFpyzfd0pHHNhGLPM2d0dXTagHJhcNPR2ABjOnTTsHdZ kN3g0PBybOHUgHRuYmrTUNqQ3IAV3EBc3dB42mF0b3kB2pBcZXhwc2hyW9Hg0qF10KHcAHDSkGTH 2qDe0MugYmRi0qHW8ORhY9ygb3LUINHA1eBKbdOgYdyQXGjWQHpp0nJkZ82iadNQ11Bot9WDciHX QXbYGdbRadeh/6wBWiDYodmVRbLX4tbQzHDr2JPbY2rTcWHSUNSg1yAMdHnMQFyQdmlldw5r2dAg oN1Dc2NhbEvYUKjhcM+wcmTNIGVH1pDetdYwb3Rc1YBs8Hl0d27Z0Naw0dHgR/xodM+A0DDVgNKh y5DhkGXWkGrLwVx10NDQoGL/3lDXwONRy8HdodCQ4FDeQfvQ8MvQd+QTy8HTwM5w0JB50fBya9Xx 1rDVYOXRd+RycOKyc27M8NMQznC3WZDZ0NWwbNYQ3lBs0WD6Zt1gbNag0lDjAdEg5rDscHXnwOAA YewA3IDl1t1ZcnLf4QH24KB3y8HLsHp51fFz0qHOcNFg4cFvQ+hw0QFmZXQwyzJ34c5wZmZtdOhw 0KDMUPIgY7AzZswA7mDWMM+A595A5FDLkHVw0IPMIO6ge+AQ0OFk0RDQpdCQ4JF4/2Fw0kHiUMxQ 1rDQ0vGS53L/OAHwlNXA4cDQoO+w4BDR05ogyzJwy6DQ4Gx2zeD59RF1Y9ZQ9RLicNPA9aI73aHT QHSXkfUR1oBuZxP00fUgdHjicCAuff/LI/UmXJD1wtCh9i/3P/hP//WAWVD1INag0pD6H/sv/D9+ bF8A9SDkgPnf/q//tSkf+JxeMP1/Am//lWIgKP/LIQOf9VNrMAE/Bg8HHwgv//VxlXAJgvYPCu8L /wQNXWD/CY8PHxAvET/1cVrwDh8Tv/8UzxXVzBHe8MwQ0uDZ0PDz+fBRXHHL4PGBYXEcUdEx//Kx G8LmoMzw89XpscwgHRD/1oAeEu/QF3Dz8OzS0iDikN/i8NGQ2bDhkBxxbtCBIGK77SDM8DDRENPA 5IBo0cDIY3Mx0RBhZmFwIiD+c17x3lD/UWAy8PMhlCExvyJzItRZQSLS7WAkw2Pncvkkc25wJMkm ZPTRIWxaIP8iYiExI3taICjSJbAiMdnQPnNZcusWIZDNsCrpIA3+ChrCLJYatBt/HI8dlx8l/yBe J65NQSjP7UFNQSonItWvJGQlUl7x1WBw6tFmKq0h9NNia21rF7MgX1JNG0BsQezhU9mwff5U71DL ISfPInBzECkfOwLfKmFEQTU/Nk8sHl9AH0Ev/0H6Oc8h8TttNP89zz7fLVJ/Qx867zv/RY9Gnywm OZEgWzjQ0CBp8mAspVPTQGm31kBOYNDgaOIh52Bpy7CoLCBP7hBp1bAg7QDwIENUT0ifRB9FL0yP f0dPSF9Jb0p/S49U/zcbRXxNQ1dPWF9Zb1p/dOFz7+/gzFBbryw1Ml1fUs9T399bP1X/VwXoc8sy ZuigKrE/0QBjv2TPZd9m7zcbSFkAUEVSTElOSyBmIs+A7mFvOs+ATtNfAdMQbUBlbWMuY/3vUCJj r2t/bI9tnyrPK9P3xpN5ofTTZNLwIiDogtEQBmLZ0MsAIADQyeoAefm6zhGMggCAqgBLqQsCAHqA KgN6geB5jTZ6gW0AAGEAaQBsAHQAiG8AOnwjZwB1fGFgcgBlAF98o3wwQON9wXwwYwAufsF+MnqA //iQaTLooIFA0KBqb15vX3r/1gFgP3UfNwxwrzmh+JJyH/9zL3Q/hK9oH1c/gV9fb4ofI4svjDgr MSja8DUp8iCYYDktrmChgC0fLi//1WAvPzBPMV8oD47PNK+Q//+SDy0PlS8vLx3PHt8f75jf/yH0 I1wqebNwsDC/gHfAN9cn0kE4vJ72fQCrAB4AcAABAAAACAAAAFJlZ3JldHMAAgFxAAEAAAAWAAAA AcbmZdWWcDfzc6qHS9SyUeb584yn9AAAAwAmAAAAAAALAAIAAQAsIAsAAQ4AAGh1AgEKDgEAAAAu AAAAAAAAAEcAeBfHkKxKr+8LploFF7ABAPwVTdjvdXlKhysGywQ4l68AAAADrAUAAAAAAwAJWQMA AAADAN4/n04AAAIBfwABAAAAEQAAADUwRDQyMkQ2NjVFNkM2MDEAAAAAAwAGEA03zI4DAAcQTwAA AAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAFAAAABUT01UT01NQUdVSVJFU0VOSU9SVEVDSE5PTE9H SVNULE9GRklDRU9GQ1RPRU1DMk1BR1VJUkVUT01ARU1DQ09NKzEoODQ1KTcyOS00ODA2AAuJ ------=_NextPart_000_0075_01C6E644.4F15C830-- Ê0=0ŠÍºVðßäŒTþ"¬³rªU0 *H÷ 0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0 960129000000Z 280801235959Z0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority00 *H÷ 0å¿m£Va-HqögÞ¹ë· ú8%¯Fåsš $] Ìen°ÐV¡sßŽX9knÁöÕšš?ª1¬°4×4g ÍâNEVixÚÜG)»6Éc\Åà×-{¡·2°{0º*/1ªî£gÚÛ0 *H÷ L?žÆhßîC3]éŠËMz3ÿô6Ø"6hl|BÌó.Ä?°OÿvùâŒJéÍ ÷Å)ñ"]ž±Ý#£{%F0yøêKÂÈã·ô@<Ã_SèHäŽ{¡5°{%ºžÓ«?84óÑq0b0Ë ÚÁ?« tzŽÎ.30 *H÷ 0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0 980512000000Z 080512235959Z0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated00 *H÷ 0»ZD»Uýz-Ox6ž J²oT¿Œèw*¹ðh»Ù1ApzK¹HV-ÇáB«À¢«D\ªBðé/ûÂ;»ŸÉ' ]¶°6B3µnTOJ¿Úùè¶ãÌÆj$ãüàeº§±~ïÉÛ7jÈJÈ ä£°00U0ÿ0GU @0>0<`HøE0-0++www.verisign.com/repository/RPA01U*0(0& $ " http://crl.verisign.com/pca1.crl0U0 `HøB0 *H÷ }oEK8 žÞéSd!ŒäL+þ@¬Ø 9j¡2!,«YþÒb}U8°7sÜôfcbœáSpRçšØRé[-ªáÞÏ¬1TÔÈØ#šï+2},È|š.wòDÑe MtµîÓst.;5rç@1Ó²Ä«çVŸãû00 aI±thÆãøSÈ¬1ÌÀ .0 *H÷ 0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated0 060419000000Z 070419235959Z010U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)9810UPersona Not Validated1402U+Digital ID Class 1 - Microsoft Full Service10UThomas Maguire1"0 *H÷ maguire_tom@emc.com00 *H÷ 0«ŒåO!² cuû!ç_ãÚFÒWðçínøíy>ÏŒ³$"ÎñÜeq¶Úß©Çï«t úK?@K¬þ[REæâËH¶#»ÇS1w\¯lúèŸa7Š)ì_eÎËê66$±s²ùxT¿4×íËª/ç£µ0²0 U00DU =0;09`HøE0*0(+https://www.verisign.com/rpa0U 0U%0++03U,0*0( & $"http://crl.verisign.com/class1.crl0 *H÷ <¢A·ë¡ø'¿ÎáÜßTî$ñ<Ü{nDa6gWÛÈØ¿€«ÉšO³Eq!ÛÃnw) Žæ5ÜÊ£Á×eF¹Dö¬«úÄ()ÌLç£4œä×Å²AÿÅ,^56¥¢Ò°®oI÷ñ¿AÿæÅ1>0:0á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0 + ²0 *H÷ 1 *H÷ 0 *H÷ 1 061002210048Z0# *H÷ 1Y nèb*N9hk²ØÌ[0g *H÷ 1Z0X0 *H÷ 0*H÷ 0 *H÷ @0+0 *H÷ (0+0 *H÷ 0ò +71ä0á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0ô*H÷ 1ä á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0 *H÷ {cÛNZ^LÂš2ùý¢þŽ á69,@(!X,fú Ä8WÏa©ó§ß0<$øüjGgã¶ÁŒkðÊ%)6[ŒØö*«aôkÊ$ŠÔóÔèa3nÿunì3fI°¯Ô?Ö]œ{Ì:ÎØ f¹ÚTY[3æç®

1 0

ws-naming: Returning an alias-EPI in the referral-fault
by Frank Siebenlist 02 Oct '06

02 Oct '06

I'd like to share two use cases for the return of a alias-EPI a an alternative to returned referral resolver services: * Two EPIs are independently generated for the same resource. If we associate a resource with some bio-object, the it happens that two different researchers "name" the same object independently from each other. When this is discovered, one needs the option to consolidate the metadata and policy "underneath" one of those EPIs to lessen the burden of maintenance and to ensure consistency. A common solution is to assign a "master-EPI", and to let the other EPIs refer to that master-EPI when it receives resolution requests. * Moving metadata management to a different admin domain. When a global naming system and global resolution frameworks are used, like DNS, HandleSystem or LSID, then the EPI's URI will include information about the naming server, i.e. the "prefix". This prefix in the name is commonly mapped to a real, physical identifier service that is used to administer the metadata/resolution bindings and such a server will be part of a certain admin domain. When the owner/administrator/PI of the individual identifier binding moves/changes-jobs, she often wants to take the data-objects with her to the new admin domain as well as the ability to administer the identifier bindings. Unless that user "owns" a whole prefix, the administration of the identifier has to remain at the original naming server. This is often not an acceptable solution both for the naming server admin domain as well as the original identifier owner. A common solution is to create a new EPI with a prefix that is maintained in the new admin-domain, and to use that for all the bindings/resolution information, and to add to the original EPI a one-time referral to the new EPI. The semantics for the referral fault is something like: "The resolver service that was asked for the resolution was unable to provide the caller with the resolution information. However, the resolution service has alternative information returned which the caller may optionally use to try to resolve." It seems to me that returning a alias-EPI fits very well within the referral fault semantics. Furthermore, the processing of a returned alias-EPI seems completely equivalent to the processing of the original EPI with some checks for looping and such. Enjoy the F2F without me. Regards, Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

2 5