<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Shib Users,</div><div><br></div><div>Gluu has recently integrated OneID, see Press Release at: <a href="http://goo.gl/s9gmW">http://goo.gl/s9gmW</a></div><div><br></div><div>In combination with the Shibboleth OX Login Handler (see release at: <a href="http://goo.gl/VbXvQ">http://goo.gl/VbXvQ</a>), you can now use OneID to login to SAML websites.</div><div><br></div><div>The login handler can be found in our public SVN: <a href="https://svn.gluu.info/repository/openxdi/oxAuth/ShibIdpClient">https://svn.gluu.info/repository/openxdi/oxAuth/ShibIdpClient</a> </div><div><br></div><div>If you have any questions, you can find our mailing lists at:</div><div><a href="http://ox.gluu.org/doku.php?id=resources:mailing_lists">http://ox.gluu.org/doku.php?id=resources:mailing_lists</a></div><div><br></div><div><br></div><div>Thanks all!</div><div>Will</div><div><br></div><div><br></div><div><div>On Mar 26, 2013, at 11:00 AM, <a href="mailto:users-request@shibboleth.net">users-request@shibboleth.net</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Send users mailing list submissions to<br><span class="Apple-tab-span" style="white-space:pre"> </span><a href="mailto:users@shibboleth.net">users@shibboleth.net</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br><span class="Apple-tab-span" style="white-space:pre"> </span>http://shibboleth.net/mailman/listinfo/users<br>or, via email, send a message with subject or body 'help' to<br><span class="Apple-tab-span" style="white-space:pre"> </span>users-request@shibboleth.net<br><br>You can reach the person managing the list at<br><span class="Apple-tab-span" style="white-space:pre"> </span>users-owner@shibboleth.net<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of users digest..."<br><br><br>Today's Topics:<br><br> 1. Re: Using Metadata in my App (Cantor, Scott)<br> 2. Re: Using Metadata in my App (Tom Scavo)<br> 3. Re: Using Metadata in my App (Cantor, Scott)<br> 4. Re: Using Metadata in my App (Andy Bennett)<br> 5. Re: Using Metadata in my App (Cantor, Scott)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Tue, 26 Mar 2013 14:46:41 +0000<br>From: "Cantor, Scott" <cantor.2@osu.edu><br>Subject: Re: Using Metadata in my App<br>To: Shib Users <users@shibboleth.net><br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><BA63CEAE152A7742B854C678D94913836C766850@CIO-KRC-D1MBX01.osuad.osu.edu><br><span class="Apple-tab-span" style="white-space:pre"> </span><br>Content-Type: text/plain; charset="us-ascii"<br><br>On 3/26/13 8:20 AM, "Andy Bennett" <andyjpb@knodium.com> wrote:<br><br><blockquote type="cite">At the moment I get Shib-Identity-Provider which is a URI and either<br></blockquote><blockquote type="cite">targeted-id which is <letters>@<scope> or persistent-id which is<br></blockquote><blockquote type="cite"><IdP-URI>!<SP-URI>!<letters>.<br></blockquote><br>It's whatever you choose to serialize it into with the software via the<br>decoder rule. The underlying data is a SAML NameID element in XML with a<br>three part structure, value, SP qualifier, and IdP qualifier.<br><br>The first thing you probably need to do is read this:<br>https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID<br><br>That explains why there are different syntaxes floating around this and<br>what "targeted-id" is (a legacy name for a broken syntax that was<br>accidentally adopted).<br><br>None of what you're talking about is eduPersonPrincipalName (responding to<br>Tom). Different attribute with different properties entirely.<br><br><blockquote type="cite">Shib-Identity-Provider seems to equal <IdP-URI>. Is this always the<br></blockquote><blockquote type="cite">case?<br></blockquote><br>In practice. Not in terms of the definition of SAML persistent IDs, no.<br><br><blockquote type="cite">If an IdP changes their entityID will the value of<br></blockquote><blockquote type="cite">Shib-Identity-Provider change? Will I still get the same persistent-id<br></blockquote><blockquote type="cite">for that individual? What about targeted-id?<br></blockquote><br>The value is the opaque part. The qualifiers are the entityIDs. If those<br>change, the qualifiers usually change. How that affects your application<br>depends on what you do with the data. You might have to rekey, yes.<br><br>And targeted-id is broken, by definition. You can read the page I pointed<br>to and see how to avoid ever seeing it.<br><br><blockquote type="cite">I find it quite challenging to work through the attribute-map.xml and<br></blockquote><blockquote type="cite">get a good idea of what will actually end up in my FCGI Variables.<br></blockquote><br>I can't really respond unless I know what it is you're confused about in<br>the file. The most confusing thing is the nonsense around persistent and<br>targeted IDs.<br><br><blockquote type="cite">When a user logs in I look up or create the IdP entry based on<br></blockquote><blockquote type="cite">Shib-Identity-Provider. This entry tells me whether we like to use<br></blockquote><blockquote type="cite">targeted-id or persistent-id as the key for these users.<br></blockquote><br>You may not need to do that if you decode the broken form into a form that<br>looks the same as the non-broken form.<br><br><blockquote type="cite">This is similar to the case my original eMail was trying to target. I<br></blockquote><blockquote type="cite">currently have a bunch of IdP entries in my database and I want to<br></blockquote><blockquote type="cite">create a bunch of "Organisation" entries and then associate them with<br></blockquote><br>That's a perfectly fine thing to want, but neither the entityID nor<br>anything that's in SAML metadata is an organizational identifier. The<br>history of such things is that we have no standard for such a thing,<br>because every application tends to have its own views of what it's trying<br>to identify. There are many, many schemas for identifying organizations,<br>but they don't span applications.<br><br>I think, personally, that federation creates an opportunity for revisiting<br>that question because so many different applications rely on this common<br>infrastructure. But we haven't done it, and even if we did, no other<br>verticals would probably follow us, which puts the SPs in the same<br>situation, no common standard.<br><br>-- Scott<br><br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Tue, 26 Mar 2013 10:47:56 -0400<br>From: Tom Scavo <trscavo@gmail.com><br>Subject: Re: Using Metadata in my App<br>To: Andy Bennett <andyjpb@knodium.com><br>Cc: Shib Users <users@shibboleth.net><br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><CAEtu=dOC3mtsHZJahiGfWGpeNXU-==r5jNcJWUy1=Vhc0TXd3w@mail.gmail.com><br>Content-Type: text/plain; charset=ISO-8859-1<br><br>On Tue, Mar 26, 2013 at 10:23 AM, Andy Bennett <andyjpb@knodium.com> wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">Some IdPs send me an opaque targeted-id, some send an opaque<br></blockquote><blockquote type="cite">persistent-id triple and some send a less opaque eppn plus and opaque<br></blockquote><blockquote type="cite">targeted-id.<br></blockquote><br>Well, there's a (conceptual) problem here since "opaque targeted-id"<br>and "opaque persistent-id triple" are almost certainly the same thing.<br><br><blockquote type="cite"> <!-- Second, an alternate decoder that will decode the incorrect<br></blockquote><blockquote type="cite">form into the newer form. --><br></blockquote><blockquote type="cite"> <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"<br></blockquote><blockquote type="cite">id="persistent-id"><br></blockquote><blockquote type="cite"> <AttributeDecoder xsi:type="NameIDFromScopedAttributeDecoder"<br></blockquote><blockquote type="cite">formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQua<br></blockquote><blockquote type="cite">lifiers="true"/><br></blockquote><blockquote type="cite"> </Attribute><br></blockquote><br>This is the pre-SAML2 form of ePTID.<br><br><blockquote type="cite"> <!-- Third, the new version (note the OID-style name): --><br></blockquote><blockquote type="cite"> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" id="persistent-id"><br></blockquote><blockquote type="cite"> <AttributeDecoder xsi:type="NameIDAttributeDecoder"<br></blockquote><blockquote type="cite">formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="t<br></blockquote><blockquote type="cite">rue"/><br></blockquote><blockquote type="cite"> </Attribute><br></blockquote><br>This is the SAML2 form of ePTID.<br><br><blockquote type="cite"> <!-- Fourth, the SAML 2.0 NameID Format: --><br></blockquote><blockquote type="cite"> <Attribute<br></blockquote><blockquote type="cite">name="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"<br></blockquote><blockquote type="cite">id="persistent-id"><br></blockquote><blockquote type="cite"> <AttributeDecoder xsi:type="NameIDAttributeDecoder"<br></blockquote><blockquote type="cite">formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="t<br></blockquote><blockquote type="cite">rue"/><br></blockquote><blockquote type="cite"> </Attribute><br></blockquote><br>This is the SAML2 Persistent NameID, which is 100% equivalent to the<br>SAML2 form of ePTID.<br><br><blockquote type="cite">I'm not using this one:<br></blockquote><blockquote type="cite">-----<br></blockquote><blockquote type="cite"> <!-- First, the deprecated/incorrect version, decoded as a scoped<br></blockquote><blockquote type="cite">string: --><br></blockquote><blockquote type="cite"> <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"<br></blockquote><blockquote type="cite">id="targeted-id"><br></blockquote><blockquote type="cite"> <AttributeDecoder xsi:type="ScopedAttributeDecoder"/><br></blockquote><blockquote type="cite"> <!-- <AttributeDecoder<br></blockquote><blockquote type="cite">xsi:type="NameIDFromScopedAttributeDecoder"<br></blockquote><blockquote type="cite">formatter="$NameQualifier!$SPNameQualifier!$Name" defau<br></blockquote><blockquote type="cite">ltQualifiers="true"/> --><br></blockquote><blockquote type="cite"> </Attribute><br></blockquote><blockquote type="cite">-----<br></blockquote><br>I don't see how that's different than the first one above. Someone<br>else more knowledgeable about the Shib SP will have to review.<br><br><blockquote type="cite"><blockquote type="cite">I think you mean ePPN, in which case, yes, ePPN is globally unique.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">...but I don't get access to the raw ePPN from the SAML exchange. I just<br></blockquote><blockquote type="cite">get some decoded value that involves the entityIDs from "various"<br></blockquote><blockquote type="cite">places. It's not clear to me whether those entityIDs come from the<br></blockquote><blockquote type="cite">configuration (shibboleth2.xml for SP-ID, federation XML for IdP-ID) or<br></blockquote><blockquote type="cite">from the SAML exchange / IdP database backend.<br></blockquote><br>All I can say for sure is the values supplied to the application do<br>NOT come from metadata. They are asserted by the IdP just-in-time.<br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">What about targeted-id?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Technically, no, since ePTID is a triple, one component of which is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the IdP's entityID. If the ePTID value was computed correctly by the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">IdP to being with, you would still obtain that same value after their<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">entityID had changed.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I'm confused. How is that different than from persistent-id? Surely<br></blockquote><blockquote type="cite">anything involving the entityID will change?<br></blockquote><br>Yes, I agree, there's confusion :-)<br><br><blockquote type="cite"><blockquote type="cite">Your goal is laudable but unfortunately the typical SAML metadata file<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">is not up to the task. For an interesting counterexample, see the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">SWITCH metadata:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">http://metadata.aai.switch.ch/metadata.switchaai.xml<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Notice the value of the OrganizationName element in each case.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Brilliant, eh? :-)<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">That looks interesting. The OrganizationName seems to be terse but<br></blockquote><blockquote type="cite">potentially helpful and then they supply human readable names in a<br></blockquote><blockquote type="cite">number of languages in the OrganizationDisplayName attribute.<br></blockquote><blockquote type="cite">It looks like they keep OrganizationName the same for multiple IdPs and<br></blockquote><blockquote type="cite">SPs from the same organisation. Who knows if they guarantee it.<br></blockquote><br>The SWITCH folks frequent this list so someone will respond, I'm sure.<br><br>Cheers,<br>Tom<br><br><br>------------------------------<br><br>Message: 3<br>Date: Tue, 26 Mar 2013 14:54:21 +0000<br>From: "Cantor, Scott" <cantor.2@osu.edu><br>Subject: Re: Using Metadata in my App<br>To: Shib Users <users@shibboleth.net>, Andy Bennett<br><span class="Apple-tab-span" style="white-space:pre"> </span><andyjpb@knodium.com><br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><BA63CEAE152A7742B854C678D94913836C7668B4@CIO-KRC-D1MBX01.osuad.osu.edu><br><span class="Apple-tab-span" style="white-space:pre"> </span><br>Content-Type: text/plain; charset="us-ascii"<br><br>On 3/26/13 10:47 AM, "Tom Scavo" <trscavo@gmail.com> wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">I don't see how that's different than the first one above. Someone<br></blockquote><blockquote type="cite">else more knowledgeable about the Shib SP will have to review.<br></blockquote><br>https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID<br><br><blockquote type="cite">All I can say for sure is the values supplied to the application do<br></blockquote><blockquote type="cite">NOT come from metadata. They are asserted by the IdP just-in-time.<br></blockquote><br>They're a mix. SAML allowed qualifiers in NameIDs to be defaulted based on<br>context. If they're not sent, they can be defaulted into existence based<br>on the identities of the issuer and the recipient. The former comes from<br>the SAML response (and by design is what's in the metadata), the latter<br>comes from the SP configuration.<br><br>-- Scott<br><br><br><br><br>------------------------------<br><br>Message: 4<br>Date: Tue, 26 Mar 2013 15:07:45 +0000<br>From: Andy Bennett <andyjpb@knodium.com><br>Subject: Re: Using Metadata in my App<br>To: Shib Users <users@shibboleth.net><br>Message-ID: <5151B9C1.7050604@knodium.com><br>Content-Type: text/plain; charset="ISO-8859-1"<br><br>Hi,<br><br><blockquote type="cite">It's whatever you choose to serialize it into with the software via the<br></blockquote><blockquote type="cite">decoder rule. The underlying data is a SAML NameID element in XML with a<br></blockquote><blockquote type="cite">three part structure, value, SP qualifier, and IdP qualifier.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The first thing you probably need to do is read this:<br></blockquote><blockquote type="cite">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">That explains why there are different syntaxes floating around this and<br></blockquote><blockquote type="cite">what "targeted-id" is (a legacy name for a broken syntax that was<br></blockquote><blockquote type="cite">accidentally adopted).<br></blockquote><br>Ah yes. I remember reading that way back at the beginning when I knew<br>even less than I do now. ;-) It was worth another read tho'. Thanks.<br><br>I set up the decoders thusly in attribute-map.xml:<br><br>-----<br> <!-- First, the deprecated/incorrect version, decoded as a scoped<br>string: --><br> <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"<br>id="targeted-id"><br> <AttributeDecoder xsi:type="ScopedAttributeDecoder"/><br> <!-- <AttributeDecoder<br>xsi:type="NameIDFromScopedAttributeDecoder"<br>formatter="$NameQualifier!$SPNameQualifier!$Name" defau<br>ltQualifiers="true"/> --><br> </Attribute><br><br> <!-- Second, an alternate decoder that will decode the incorrect<br>form into the newer form. --><br> <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"<br>id="persistent-id"><br> <AttributeDecoder xsi:type="NameIDFromScopedAttributeDecoder"<br>formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQua<br>lifiers="true"/><br> </Attribute><br><br> <!-- Third, the new version (note the OID-style name): --><br> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" id="persistent-id"><br> <AttributeDecoder xsi:type="NameIDAttributeDecoder"<br>formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="t<br>rue"/><br> </Attribute><br><br> <!-- Fourth, the SAML 2.0 NameID Format: --><br> <Attribute<br>name="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"<br>id="persistent-id"><br> <AttributeDecoder xsi:type="NameIDAttributeDecoder"<br>formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="t<br>rue"/><br> </Attribute><br>-----<br><br>...and I still seem to get some IdPs who's auth comes thru with old<br>style targeted-id and no persistent-id. I wanted to get both variables<br>when IdPs were sending the old style and I was transforming it into the<br>new style in the SP. The intention was to assert that the value parts<br>were equal and then migrate.<br><br><br><br><blockquote type="cite">That's a perfectly fine thing to want, but neither the entityID nor<br></blockquote><blockquote type="cite">anything that's in SAML metadata is an organizational identifier. The<br></blockquote><blockquote type="cite">history of such things is that we have no standard for such a thing,<br></blockquote><blockquote type="cite">because every application tends to have its own views of what it's trying<br></blockquote><blockquote type="cite">to identify. There are many, many schemas for identifying organizations,<br></blockquote><blockquote type="cite">but they don't span applications.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I think, personally, that federation creates an opportunity for revisiting<br></blockquote><blockquote type="cite">that question because so many different applications rely on this common<br></blockquote><blockquote type="cite">infrastructure. But we haven't done it, and even if we did, no other<br></blockquote><blockquote type="cite">verticals would probably follow us, which puts the SPs in the same<br></blockquote><blockquote type="cite">situation, no common standard.<br></blockquote><br>Thanks for the tips. It looks like there are lengths that I can go to<br>that will allow me to reap some benefit from the data in my particular<br>Federation but there are no Silver Bullets.<br><br><br><br>Thanks!<br><br><br><br><br><br>Regards,<br>@ndy<br><br>-- <br>andyjpb@knodium.com<br>http://www.knodium.com/<br><br><br><br><br>------------------------------<br><br>Message: 5<br>Date: Tue, 26 Mar 2013 15:50:04 +0000<br>From: "Cantor, Scott" <cantor.2@osu.edu><br>Subject: Re: Using Metadata in my App<br>To: Andy Bennett <andyjpb@knodium.com>, Shib Users<br><span class="Apple-tab-span" style="white-space:pre"> </span><users@shibboleth.net><br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><BA63CEAE152A7742B854C678D94913836C7669BD@CIO-KRC-D1MBX01.osuad.osu.edu><br><span class="Apple-tab-span" style="white-space:pre"> </span><br>Content-Type: text/plain; charset="us-ascii"<br><br>On 3/26/13 11:07 AM, "Andy Bennett" <andyjpb@knodium.com> wrote:<br><br><blockquote type="cite">I set up the decoders thusly in attribute-map.xml:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-----<br></blockquote><blockquote type="cite"> <!-- First, the deprecated/incorrect version, decoded as a scoped<br></blockquote><blockquote type="cite">string: --><br></blockquote><blockquote type="cite"> <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"<br></blockquote><blockquote type="cite">id="targeted-id"><br></blockquote><blockquote type="cite"> <AttributeDecoder xsi:type="ScopedAttributeDecoder"/><br></blockquote><br>Right there you are choosing to keep processing the broken form.<br><br><blockquote type="cite">...and I still seem to get some IdPs who's auth comes thru with old<br></blockquote><blockquote type="cite">style targeted-id and no persistent-id.<br></blockquote><br>Yes, that would follow.<br><br><blockquote type="cite">I wanted to get both variables<br></blockquote><blockquote type="cite">when IdPs were sending the old style and I was transforming it into the<br></blockquote><blockquote type="cite">new style in the SP. The intention was to assert that the value parts<br></blockquote><blockquote type="cite">were equal and then migrate.<br></blockquote><br>Ah. No, it can't do that. The purpose of the new decoder was so you can<br>rekey as part of a migration and then switch the decoders. It can't deal<br>with a case where you get two different attributes with different values.<br><br>If you want both attributes, then the way you're doing it is the way you<br>would do it.<br><br>-- Scott<br><br><br><br><br>------------------------------<br><br>--<br>To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net<br><br>End of users Digest, Vol 21, Issue 81<br>*************************************<br></div></blockquote></div><br><div apple-content-edited="true">
<div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="orphans: 2; text-align: -webkit-auto; text-indent: 0px; widows: 2; -webkit-text-decorations-in-effect: none; font-size: medium; -webkit-text-stroke-width: 0px; -webkit-text-size-adjust: auto; -webkit-border-vertical-spacing: 0px; -webkit-border-horizontal-spacing: 0px; word-spacing: 0px; white-space: normal; text-transform: none; line-height: normal; letter-spacing: normal; font-weight: normal; font-variant: normal; font-style: normal; font-family: Helvetica; color: rgb(0, 0, 0); border-collapse: separate; "><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div class=""><div class=""><div class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div class="">----</div><div class="">William Lowe</div><div class=""><a href="http://linkedin.com/in/whaven" class="">http://linkedin.com/in/whaven</a></div><div class=""><div class=""><div class=""><div class=""><div class=""><a href="http://gluu.org/" class="">http://gluu.org</a></div></div></div></div></div><div class="">o: (925) 470-2230</div><div class="">m: (925) 389-7426 </div><br class="Apple-interchange-newline"><span><img height="92" width="225" id="19d558ea-2d81-43be-8247-bb7e122fabd4" apple-width="yes" apple-height="yes" src="cid:28918A24-EE94-4622-8792-0529C6C186C4@fg2.com"></span>
</div>
</div></div></div></div></div></div></div></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></div></div><br></body></html>