OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] XRD and JSON


--Apple-Mail-8--452632024
Content-Type: multipart/alternative;
	boundary=Apple-Mail-7--452632123


--Apple-Mail-7--452632123
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I think that it is fine for google to assert your relationship with =
multiple providers.

However if I am a RP and I get two entries for Flickr as a photo sharing =
service knowing who is asserting the relationship may be important.

There is also the possibility that a bad site my inject a XAuth object =
saying that you have a photo sharing relationship with some photo =
sharing account that has naughty photos.  =20

This is going to be used in a slightly different way to XRD.  =20

In XRD we assume the user has control over the XRD. =20

In XAuth unless there is a white list of providers if a RP asks for all =
the photo sharing services they may get ones that are inserted by any =
site the person has visited.

That makes it more important for the RP to know who is saying this for =
the user.

Who controls the info is different.

It is an interesting problem.   I suspect that it will need to be worked =
on in parallel with the XAuth API and service.

I guess that raises the question of what IPR policy and standards =
process XAuth is being developed under.

I suspect the google group can only go so far.  =20

John B.
On 2010-04-23, at 4:54 PM, Will Norris wrote:

> I believe that's pretty accurate.  I'm not sure if the extender =
necessarily needs to be represented inside the JSON-XRD itself, but that =
certainly wouldn't hurt anything.  I'm not sure that there is any issue =
with Google asserting Flickr information... I have made an explicit =
connection to my Flickr account from my Google profile =
(http://www.google.com/profiles/wnorris), so why shouldn't Google assert =
that (with user consent, etc)?
>=20
> -will
>=20
> On Fri, Apr 23, 2010 at 10:17 AM, John Bradley <jbradley@mac.com> =
wrote:
> So it may be better to to say that your use case requires a XRD =
preprocessor that creates a standard JSON object from a XRD (The XRD may =
or may not exist)
>=20
> The JSON object may need to be optimized differently from XRD.
>=20
> You have:
> 1.  Who is the extender  ie Google
> 2.  What is the users LocalID for the Service/relationship eg ve7jtb
> 3.  What is the rel  ie Photo sharing=20
> 4.  What is the Link  eg Flickr
>=20
> This produces interesting questions about Google asserting information =
for Flikr and Yahoo for Picassa.
>=20
> So there needs to be a transform of several XRD into JSON objects that =
the browser manipulates and returns another JSON object to the requestor =
based on the results of some query.
>=20
> The resulting JSON object may be acted upon in the browser by JS from =
the RP or returned to the RP where it may or may not be reconstituted as =
a XRD.
>=20
> There is an advantage to standardizing the JSON object because =
multiple IdP will be producing them for manipulation by Xauth and Xauth =
will be producing them for multiple RP libraries.
>=20
> Is that a far synopsis of what you are looking for?
>=20
> John B.
>=20
> On 2010-04-22, at 9:03 PM, Will Norris wrote:
>=20
>> On Thu, Apr 22, 2010 at 4:52 PM, John Bradley <jbradley@mac.com> =
wrote:
>> I don't think that Xauth has the concept of looking for things by =
service yet.
>>=20
>> correct, it doesn't support that yet... we're already looking toward =
future work.
>>=20
>> =20
>> You cant ask for all of the persons openID providers, you have to ask =
for the token of a specific extender.
>>=20
>> Is this so that the extender can push a JSON XRD to allow the JS to =
search by service/rel?
>>=20
>> exactly.
>>=20
>> =20
>> I have concerns about the privacy issues as well, but that is for a =
different forum.
>>=20
>> John B.
>> On 2010-04-22, at 6:45 PM, Will Norris wrote:
>>=20
>>> right now, we're looking at formats for storing data in an XAuth =
payload.  Certainly, one very simple thing could be flag that states =
"this user has an active session at Google", and nothing more.  But you =
could just as easily store links to various service providers. =20
>>>=20
>>> So when I login to Google, it stores a small XRD in XAuth that =
includes a link:
>>>   link: { rel: "photo-service", href: "http://picasaweb.google.com/"; =
}
>>>=20
>>> And then when I sign in to Yahoo, it also adds a link:
>>>   link: { rel: "photo-service", href: "http://flickr.com/"; }
>>>=20
>>> And then when I go to some printing service, it can prompt me to =
import my photos from Flickr or Picasa.
>>>=20
>>> there are huge potential privacy implications around this, so I =
don't know if it will even fly.  Certainly, a lot of thought has to go =
into exactly what data should be stored, who should have access, how =
access is actually controlled, etc. But conceptually, the kind of data =
that could be stored in XAuth is identical to what is stored in a user's =
XRD.  It makes a lot of sense to try and re-use XRD (or some flavor of =
it) rather than invent something new.  It's a small step towards a rich =
identity-aware user agent, but using the tools we have today.
>>>=20
>>> I'm not completely clear on how the access controls work, either for =
reading or writing data, but what I've heard has lead me to believe that =
the data does not necessarily need to be signed.
>>>=20
>>> -will
>>>=20
>>> On Thu, Apr 22, 2010 at 3:20 PM, John Bradley <jbradley@mac.com> =
wrote:
>>> Can you explain the initial use case a bit for us?
>>>=20
>>> John B.
>>>=20
>>> On 2010-04-22, at 5:45 PM, Will Norris wrote:
>>>=20
>>>> you either have:
>>>>   1) a no-brainer method of switching between XML and JSON like =
JsonML, and then have to do some work to get the JSON into the right =
logical object, or
>>>>   2) a no-brainer JSON format that can be used as-is, and you have =
to do a little work to switch between the XML and JSON formats
>>>>=20
>>>> It's just a matter of which one you want to optimize for.
>>>>=20
>>>> Signatures are of course an issue, and I don't really have an =
answer for that.  The immediate use-case we're looking at wouldn't =
necessarily need signatures, though.
>>>>=20
>>>> -will
>>>>=20
>>>>=20
>>>> On Thu, Apr 22, 2010 at 1:25 PM, John Bradley <jbradley@mac.com> =
wrote:
>>>> I am still trying to understand the use case.
>>>>=20
>>>> Having multiple discovery formats each requiring separate =
processing is not optimal.
>>>>=20
>>>> Being able to transform from one to the other may have advantages.
>>>>=20
>>>> I am speculating that the Google wants a discovery format that can =
be entirely parsed with JS inside the browser.
>>>>=20
>>>> I am not personally religious about XML.=20
>>>>=20
>>>> If a JSON  format that can be transformed into the equivalent XML =
XRD can be specified that may be a useful work product for the TC.
>>>>=20
>>>> My main concerns are around signatures if this starts being used on =
the server as well as in the browser.
>>>>=20
>>>> The Google seems to have decided this week that going outside the =
existing standards development process is more efficient.
>>>> I would prefer that this not result in competing discovery =
standards.
>>>>=20
>>>> It is worth discussing, but at the end of the day Google may need =
to do what it needs to do.
>>>>=20
>>>> John B.
>>>>=20
>>>> On 2010-04-22, at 3:04 PM, Will Norris wrote:
>>>>=20
>>>>> On Thu, Apr 22, 2010 at 10:58 AM, Scott Cantor <cantor.2@osu.edu> =
wrote:
>>>>> > JsonML does a far better job than some other similar utilities =
I've seen,
>>>>> so
>>>>> > that is certainly nice.  And for it's stated goals of providing =
a compact
>>>>> > format for transporting XML, it works great.  But that kind of =
misses the
>>>>> > point of using JSON, which is to provide an natural =
representation of the
>>>>> > object, not just a document.
>>>>>=20
>>>>> I think the document is the natural representation. A simple layer =
of code
>>>>> addresses whatever limitations might exist in the language that's =
purporting
>>>>> to be too difficult to use the document in.
>>>>>=20
>>>>> But as a matter of specification, the problem you have is that, =
like SAML,
>>>>> there's an explicit characterization of the notion of an XRD as =
being XML.
>>>>> If it's not XML, it's not an XRD. I have not seen a simple way =
around that.
>>>>>=20
>>>>> A separate specification can be created to establish an =
interchange format
>>>>> in some other encoding with a different label attached to it, but =
if the
>>>>> goal here was to allow for non-XML representations of an XRD, it =
would
>>>>> require some fairly big changes that I'm pretty comfortable saying =
nobody
>>>>> wants to take on.
>>>>>=20
>>>>> certainly, I wasn't meaning to suggest a departure of any kind =
from how XRD is defined today.  I've been quite upfront from the =
beginning of my involvement with this TC that I view XRD (as it's =
specified) solely as an XML format, and if you want something else, then =
do it yourself.  Well, now Google is sort of doing it ourselves, and we =
figured that if others end up wanting to do the same, it might be good =
to have agreement on what that JSON format looks like.  That could just =
be a whitepaper, a best practice guide, or whatever.  It certainly =
doesn't have to be a product of this TC, I just thought I would see if =
it was anything folks had any interest in it.
>>>>>=20
>>>>> -will
>>>>=20
>>>>=20
>>>=20
>>>=20
>>=20
>>=20
>=20
>=20


--Apple-Mail-7--452632123
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I =
think that it is fine for google to assert your relationship with =
multiple providers.<div><br></div><div>However if I am a RP and I get =
two entries for Flickr as a photo sharing service knowing who is =
asserting the relationship may be =
important.</div><div><br></div><div>There is also the possibility that a =
bad site my inject a XAuth object saying that you have a photo sharing =
relationship with some photo sharing account that has naughty photos. =
&nbsp;&nbsp;</div><div><br></div><div>This is going to be used in a =
slightly different way to XRD. &nbsp;&nbsp;</div><div><br></div><div>In =
XRD we assume the user has control over the XRD. =
&nbsp;</div><div><br></div><div>In XAuth unless there is a white list of =
providers if a RP asks for all the photo sharing services they may get =
ones that are inserted by any site the person has =
visited.</div><div><br></div><div>That makes it more important for the =
RP to know who is saying this for the user.</div><div><br></div><div>Who =
controls the info is different.</div><div><br></div><div>It is an =
interesting problem. &nbsp; I suspect that it will need to be worked on =
in parallel with the XAuth API and service.</div><div><br></div><div>I =
guess that raises the question of what IPR policy and standards process =
XAuth is being developed under.</div><div><br></div><div>I suspect the =
google group can only go so far. =
&nbsp;&nbsp;</div><div><br></div><div>John B.</div><div><div><div>On =
2010-04-23, at 4:54 PM, Will Norris wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite">I believe =
that's pretty accurate. &nbsp;I'm not sure if the extender necessarily =
needs to be represented inside the JSON-XRD itself, but that certainly =
wouldn't hurt anything. &nbsp;I'm not sure that there is any issue with =
Google asserting Flickr information... I have made an explicit =
connection to my Flickr account from my Google profile (<meta =
http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><a =
href=3D"http://www.google.com/profiles/wnorris";>http://www.google.com/prof=
iles/wnorris</a>), so why shouldn't Google assert that (with user =
consent, etc)?<div>

<br></div><div>-will<br><br><div class=3D"gmail_quote">On Fri, Apr 23, =
2010 at 10:17 AM, John Bradley <span dir=3D"ltr">&lt;<a =
href=3D"mailto:jbradley@mac.com";>jbradley@mac.com</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div style=3D"word-wrap:break-word">So it may be better to to say that =
your use case requires a XRD preprocessor that creates a standard JSON =
object from a XRD (The XRD may or may not exist)<div><br></div><div>The =
JSON object may need to be optimized differently from XRD.</div>

<div><br></div><div>You have:</div><div>1. &nbsp;Who is the extender =
&nbsp;ie Google</div><div>2. &nbsp;What is the users LocalID for the =
Service/relationship eg ve7jtb</div><div>3. &nbsp;What is the rel =
&nbsp;ie Photo sharing&nbsp;</div><div>4. &nbsp;What is the Link =
&nbsp;eg Flickr</div>

<div><br></div><div>This produces interesting questions about Google =
asserting information for Flikr and Yahoo for =
Picassa.</div><div><br></div><div>So there needs to be a transform of =
several XRD into JSON objects that the browser manipulates and returns =
another JSON object to the requestor based on the results of some =
query.</div>

<div><br></div><div>The resulting JSON object may be acted upon in the =
browser by JS from the RP or returned to the RP where it may or may not =
be reconstituted as a XRD.</div><div><br></div><div>There is an =
advantage to standardizing the JSON object because multiple IdP will be =
producing them for manipulation by Xauth and Xauth will be producing =
them for multiple RP libraries.</div>

<div><br></div><div>Is that a far synopsis of what you are looking =
for?</div><div><br></div><div>John B.<div><div></div><div =
class=3D"h5"><br><div><div>On 2010-04-22, at 9:03 PM, Will Norris =
wrote:</div><br><blockquote type=3D"cite">

<div class=3D"gmail_quote">On Thu, Apr 22, 2010 at 4:52 PM, John Bradley =
<span dir=3D"ltr">&lt;<a href=3D"mailto:jbradley@mac.com"; =
target=3D"_blank">jbradley@mac.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">



<div style=3D"word-wrap:break-word">I don't think that Xauth has the =
concept of looking for things by service =
yet.</div></blockquote><div><br></div><div>correct, it doesn't support =
that yet... we're already looking toward future work.</div>



<div><br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>You =
cant ask for all of the persons openID providers, you have to ask for =
the token of a specific extender.</div>



<div><br></div><div>Is this so that the extender can push a JSON XRD to =
allow the JS to search by =
service/rel?</div></div></blockquote><div><br></div><div>exactly.</div><di=
v><br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style=3D"word-wrap:break-word"><div>I have concerns about the =
privacy issues as well, but that is for a different =
forum.</div><div><div></div><div><div><br></div><div>John =
B.<br><div><div>On 2010-04-22, at 6:45 PM, Will Norris wrote:</div>



<br><blockquote type=3D"cite">right now, we're looking at formats for =
storing data in an XAuth payload. &nbsp;Certainly, one very simple thing =
could be flag that states "this user has an active session at Google", =
and nothing more. &nbsp;But you could just as easily store links to =
various service providers. &nbsp;<div>





<br></div><div>So when I login to Google, it stores a small XRD in XAuth =
that includes a link:<div>&nbsp;&nbsp;link: { rel: "photo-service", =
href: "<a href=3D"http://picasaweb.google.com/"; =
target=3D"_blank">http://picasaweb.google.com/</a>" }</div>





<div><br></div><div>And then when I sign in to Yahoo, it also adds a =
link:</div><div>&nbsp;&nbsp;link: { rel: "photo-service", href: "<a =
href=3D"http://flickr.com/"; target=3D"_blank">http://flickr.com/</a>" =
}</div>



<div><br></div><div>

And then when I go to some printing service, it can prompt me to import =
my photos from Flickr or Picasa.</div><div><br></div><div>there are huge =
potential privacy implications around this, so I don't know if it will =
even fly. &nbsp;Certainly, a lot of thought has to go into exactly what =
data should be stored, who should have access, how access is actually =
controlled, etc. But conceptually, the kind of data that could be stored =
in XAuth is identical to what is stored in a user's XRD. &nbsp;It makes =
a lot of sense to try and re-use XRD (or some flavor of it) rather than =
invent something new. &nbsp;It's a small step towards a rich =
identity-aware user agent, but using the tools we have today.</div>





<div><br></div><div>I'm not completely clear on how the access controls =
work, either for reading or writing data, but what I've heard has lead =
me to believe that the data does not necessarily need to be =
signed.</div>





<div><br></div><div>-will</div><div><br><div class=3D"gmail_quote">On =
Thu, Apr 22, 2010 at 3:20 PM, John Bradley <span dir=3D"ltr">&lt;<a =
href=3D"mailto:jbradley@mac.com"; =
target=3D"_blank">jbradley@mac.com</a>&gt;</span> wrote:<br>



<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style=3D"word-wrap:break-word">Can you explain the initial use case =
a bit for us?<div><br></div><div>John =
B.<div><div></div><div><br><div><div>On 2010-04-22, at 5:45 PM, Will =
Norris wrote:</div><br><blockquote type=3D"cite">





you either have:<div>&nbsp;&nbsp;1) a no-brainer method of switching =
between XML and JSON like JsonML, and then have to do some work to get =
the JSON into the right logical object, or</div><div>&nbsp;&nbsp;2) a =
no-brainer JSON format that can be used as-is, and you have to do a =
little work to switch between the XML and JSON formats</div>







<div><br></div><div>It's just a matter of which one you want to optimize =
for.</div><div><br></div><div>Signatures are of course an issue, and I =
don't really have an answer for that. &nbsp;The immediate use-case we're =
looking at wouldn't necessarily need signatures, though.</div>







<div><br></div><div>-will</div><div><br><br><div class=3D"gmail_quote">On =
Thu, Apr 22, 2010 at 1:25 PM, John Bradley <span dir=3D"ltr">&lt;<a =
href=3D"mailto:jbradley@mac.com"; =
target=3D"_blank">jbradley@mac.com</a>&gt;</span> wrote:<br>





<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style=3D"word-wrap:break-word">I am still trying to understand the =
use case.<div><br></div><div>Having multiple discovery formats each =
requiring separate processing is not =
optimal.</div><div><br></div><div>Being able to transform from one to =
the other may have advantages.</div>







<div><br></div><div>I am speculating that the Google wants a discovery =
format that can be entirely parsed with JS inside the =
browser.</div><div><br></div><div>I am not personally religious about =
XML.&nbsp;</div><div><br></div>







<div>If a JSON &nbsp;format that can be transformed into the equivalent =
XML XRD can be specified that may be a useful work product for the =
TC.</div><div><br></div><div>My main concerns are around signatures if =
this starts being used on the server as well as in the browser.</div>







<div><br></div><div>The Google seems to have decided this week that =
going outside the existing standards development process is more =
efficient.</div><div>I would prefer that this not result in competing =
discovery standards.</div>







<div><br></div><div>It is worth discussing, but at the end of the day =
Google may need to do what it needs to do.</div><div><br></div><div>John =
B.</div><div><div></div><div><div><br><div><div>On 2010-04-22, at 3:04 =
PM, Will Norris wrote:</div>







<br><blockquote type=3D"cite"><div class=3D"gmail_quote">On Thu, Apr 22, =
2010 at 10:58 AM, Scott Cantor <span dir=3D"ltr">&lt;<a =
href=3D"mailto:cantor.2@osu.edu"; =
target=3D"_blank">cantor.2@osu.edu</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">









<div>&gt; JsonML does a far better job than some other similar utilities =
I've seen,<br>
so<br>
&gt; that is certainly nice. &nbsp;And for it's stated goals of =
providing a compact<br>
&gt; format for transporting XML, it works great. &nbsp;But that kind of =
misses the<br>
&gt; point of using JSON, which is to provide an natural representation =
of the<br>
&gt; object, not just a document.<br>
<br>
</div>I think the document is the natural representation. A simple layer =
of code<br>
addresses whatever limitations might exist in the language that's =
purporting<br>
to be too difficult to use the document in.<br>
<br>
But as a matter of specification, the problem you have is that, like =
SAML,<br>
there's an explicit characterization of the notion of an XRD as being =
XML.<br>
If it's not XML, it's not an XRD. I have not seen a simple way around =
that.<br>
<br>
A separate specification can be created to establish an interchange =
format<br>
in some other encoding with a different label attached to it, but if =
the<br>
goal here was to allow for non-XML representations of an XRD, it =
would<br>
require some fairly big changes that I'm pretty comfortable saying =
nobody<br>
wants to take on.</blockquote><div><br></div><div>certainly, I wasn't =
meaning to suggest a departure of any kind from how XRD is defined =
today. &nbsp;I've been quite upfront from the beginning of my =
involvement with this TC that I view XRD (as it's specified) solely as =
an XML format, and if you want something else, then do it yourself. =
&nbsp;Well, now Google is sort of doing it ourselves, and we =
figured&nbsp;that if others end up wanting to do the same, it might be =
good to have agreement on what that JSON format looks like. &nbsp;That =
could just be a whitepaper, a best practice guide, or whatever. &nbsp;It =
certainly doesn't have to be a product of this TC, I just thought I =
would see if it was anything folks had any interest in it.</div>









<div><br></div><div>-will</div></div>
=
</blockquote></div><br></div></div></div></div></blockquote></div><br></di=
v>
=
</blockquote></div><br></div></div></div></div></blockquote></div><br></di=
v></div>
</blockquote></div><br></div></div></div></div></blockquote></div><br>
=
</blockquote></div><br></div></div></div></div></blockquote></div><br></di=
v>
</blockquote></div><br></div></body></html>=

--Apple-Mail-7--452632123--

--Apple-Mail-8--452632024
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw
ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU
T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp
YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm
aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk
bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9
Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8
k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd
NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB
+rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK
7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV
HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B
MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h
Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt
ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD
b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p
dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh
dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa
MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw
Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG
AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI
KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50
LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF
BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3
Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz
lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy
Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3
toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG
SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM
MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt
YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ
A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ
gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1
13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU
euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/
MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB
nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp
MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9
BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh
LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js
LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB
VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv
aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh
cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM
ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5
IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw
EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF
AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p
ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4
ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB
9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT
e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW
0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+
BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw
vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ
x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW
yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0
ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr
DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0
MjMyMTU3MDhaMCMGCSqGSIb3DQEJBDEWBBSaX37pOx9qLgsHHJEuVFG23LThYjCBpAYJKwYBBAGC
NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC
AQANBh1P0uzSjJrbu6DJzExXnUgKukCy8hzP2iBHv0dUuBmm1AZ/2bZG94/9xZeVg5rp6xNPwA8l
cwYuqp7KVVAulu5eyvpM8yW9LhgpjW7ALjzACT0/qIqioT38l1Qof2waQGCPLx+75hDtj+pPVupL
2J5Pff+pvTYKvxI6JkBq1gIKLvOvZYGfR8mBeOf6g6wnWxnKEwtZ/PMIwFvgWRteFHrY/VSzdP6b
mlWFgk187vi71pMUq4ndUIKHD5BpPY3OOgFW+aytyjsllAgRksn+dGIJY8QndKF4G35qniPpeD/w
6f/KrDcBHoGrdUV8+QXV9brPew7S11x1J59Jb3kRAAAAAAAA

--Apple-Mail-8--452632024--


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]