[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. = </div><div><br></div><div>This is going to be used in a = slightly different way to XRD. </div><div><br></div><div>In = XRD we assume the user has control over the XRD. = </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. 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. = </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. 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 (<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"><<a = href=3D"mailto:jbradley@mac.com">jbradley@mac.com</a>></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. Who is the extender = ie Google</div><div>2. What is the users LocalID for the = Service/relationship eg ve7jtb</div><div>3. What is the rel = ie Photo sharing </div><div>4. What is the Link = 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"><<a href=3D"mailto:jbradley@mac.com" = target=3D"_blank">jbradley@mac.com</a>></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> </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> </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. 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. <div> <br></div><div>So when I login to Google, it stores a small XRD in XAuth = that includes a link:<div> 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> 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. 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.</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"><<a = href=3D"mailto:jbradley@mac.com" = target=3D"_blank">jbradley@mac.com</a>></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> 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> 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. 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"><<a = href=3D"mailto:jbradley@mac.com" = target=3D"_blank">jbradley@mac.com</a>></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. </div><div><br></div> <div>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.</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"><<a = href=3D"mailto:cantor.2@osu.edu" = target=3D"_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"> <div>> JsonML does a far better job than some other similar utilities = I've seen,<br> so<br> > that is certainly nice. And for it's stated goals of = providing a compact<br> > format for transporting XML, it works great. But that kind of = misses the<br> > point of using JSON, which is to provide an natural representation = of the<br> > 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. 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.</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]