<div>sir, i want start feedback their mobile, so i request please solve my problem </div>
<div>thank you</div>
<div> <br><br> </div>
<div><span class="gmail_quote"> On 8/4/08, <b class="gmail_sendername"><a href="mailto:general-request@openid.net">general-request@openid.net</a></b> <<a href="mailto:general-request@openid.net">general-request@openid.net</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Send general mailing list submissions to<br> <a href="mailto:general@openid.net">general@openid.net</a><br>
<br>To subscribe or unsubscribe via the World Wide Web, visit<br> <a href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a><br>or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:general-request@openid.net">general-request@openid.net</a><br><br>You can reach the person managing the list at<br> <a href="mailto:general-owner@openid.net">general-owner@openid.net</a><br><br>
When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of general digest..."<br><br><br>Today's Topics:<br><br> 1. Re: OpenID'09 Program Launch - You are all invited to<br>
participate! (SitG Admin)<br> 2. Re: Musing on FaceBook, OpenID and the next mountain to<br> climb (Johnny Bufu)<br> 3. Re: Secure attribute transmission (Johnny Bufu)<br> 4. Re: Secure attribute transmission (Andrew Arnott)<br>
5. Re: Secure attribute transmission (Andrew Arnott)<br> 6. Re: Secure attribute transmission (Peter Williams)<br> 7. Re: Secure attribute transmission (Nate Klingenstein)<br> 8. Re: Secure attribute transmission (Nate Klingenstein)<br>
<br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Sun, 3 Aug 2008 12:05:12 -0700<br>From: SitG Admin <<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>><br>
Subject: Re: [OpenID] OpenID'09 Program Launch - You are all invited<br> to participate!<br>To: "Julian Granger-Bevan" <<a href="mailto:julian.granger-bevan@magnity.co.uk">julian.granger-bevan@magnity.co.uk</a>>, tom<br>
<<a href="mailto:tom@barnraiser.org">tom@barnraiser.org</a>><br>Cc: <a href="mailto:general@openid.net">general@openid.net</a><br>Message-ID: <f06110403c4bbaee6f9ac@[<a href="http://192.168.0.2">192.168.0.2</a>]><br>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"<br><br>At 2:39 PM +0200 8/3/08, tom wrote:<br>>You mention that discussions on list are often not picked up and I<br>>agree, but I think that is because of the lack of focal area that the<br>
<br>I think that another reason could be the transient nature of E-mail;<br>once posted, soon forgotten? Or not, but my point is that it's easy<br>to lose track of messages, and as the community grows (and, along<br>with it, the rate of discussion on this list), it'll be more and more<br>
difficult to go back through the archives looking for particular<br>discussions. This is even harder if you weren't around to receive the<br>E-mail's back then!<br><br>As another solution (in addition to your proposal), I'd like to see<br>
an area of either wiki (<a href="http://openid.net">openid.net</a> or OpenID'09) devoted to keeping<br>track of which informative or potentially useful messages have been<br>posted to the archives, and linking back to them. That way,<br>
interested parties could quickly find what they were looking for; or,<br>simply browse through old ideas and solutions waiting for their<br>problems ;)<br><br>At 11:26 AM +0100 8/3/08, Julian Granger-Bevan wrote:<br>>Surely it will help most if all of the information for the site is<br>
>situated within the one main domain.<br><br>I think the idea here was to separate information that was intended<br>for general consumption, from information aimed more at the<br>Foundation/Community; this can reduce confusion in the average user<br>
who visits <a href="http://openid.net">openid.net</a> just trying to learn what this is all about.<br><br>-Shade<br><br><br>------------------------------<br><br>Message: 2<br>Date: Sun, 03 Aug 2008 14:08:36 -0700<br>From: Johnny Bufu <<a href="mailto:johnny.bufu@gmail.com">johnny.bufu@gmail.com</a>><br>
Subject: Re: [OpenID] Musing on FaceBook, OpenID and the next mountain<br> to climb<br>To: Eran Hammer-Lahav <<a href="mailto:eran@hueniverse.com">eran@hueniverse.com</a>><br>Cc: OpenID <<a href="mailto:general@openid.net">general@openid.net</a>><br>
Message-ID: <<a href="mailto:48961E54.9090405@gmail.com">48961E54.9090405@gmail.com</a>><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br><br>On 02/08/08 03:00 PM, Eran Hammer-Lahav wrote:<br>> My comments were specific about the technical details of their platform.<br>
> The fact that instead of using a community specification they decided to<br>> create yet another protocol is what I was referring to. I would give<br>> them a high score if they used OAuth but still kept their system closed<br>
> and data private. They could have created the exact same product by<br>> building it on top of OAuth. They could have also made it friendlier to<br>> OpenID or even use OpenID as the basis but I think OAuth would have been<br>
> an easier match and lighter on the politics.<br><br>I would be interested to learn directly from Facebook what their high<br>level requirements were and why they chose not to use OAuth/OpenID.<br><br>Since I haven't seen anyone from Facebook commenting on the openid<br>
general list, what channels would they prefer? Dick, do you have any<br>insights here?<br><br><br>Johnny<br><br><br>------------------------------<br><br>Message: 3<br>Date: Sun, 03 Aug 2008 14:17:04 -0700<br>From: Johnny Bufu <<a href="mailto:johnny.bufu@gmail.com">johnny.bufu@gmail.com</a>><br>
Subject: Re: [OpenID] Secure attribute transmission<br>To: <a href="mailto:Easysurfer@gmx.de">Easysurfer@gmx.de</a><br>Cc: OpenID List <<a href="mailto:general@openid.net">general@openid.net</a>><br>Message-ID: <<a href="mailto:48962050.9060908@gmail.com">48962050.9060908@gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br><br><br>On 03/08/08 11:27 AM, <a href="mailto:Easysurfer@gmx.de">Easysurfer@gmx.de</a> wrote:<br>> I'd like to transmit sensitive data over the Attribute Exchange Extension and was wondering about the best way for encryption.<br>
[...]<br>> Any ideas? I'd like to pass the info over using only the OpenID<br>> protocol, not invent another protocol for my own use.<br><br>If what you're trying to avoid is the exchange of another secret key<br>
(and not require the RP to offer a HTTPS endpoint), then your only<br>option is to enforce statefull mode and use the shared association<br>secret to encrypt the attributes.<br><br>Otherwise, the exchange of the encryption key can be done through<br>
attribute exchange. Working with the same assumption that RPs can't<br>generally afford HTTPS endpoints, the key exchange would have to be<br>initiated by the RP against a HTTPS OP endpoint, e.g. through a AX store<br>
request.<br><br><br>Johnny<br><br><br><br>------------------------------<br><br>Message: 4<br>Date: Sun, 3 Aug 2008 14:45:53 -0700<br>From: "Andrew Arnott" <<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>><br>
Subject: Re: [OpenID] Secure attribute transmission<br>To: "SitG Admin" <<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>><br>Cc: <a href="mailto:general@openid.net">general@openid.net</a>, <a href="mailto:Easysurfer@gmx.de">Easysurfer@gmx.de</a><br>
Message-ID:<br> <<a href="mailto:216e54900808031445w47c42ad2gc6329f2d941e65a@mail.gmail.com">216e54900808031445w47c42ad2gc6329f2d941e65a@mail.gmail.com</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br>
<br>The openid.response_nonce won't be helpful here. If your RP can work only<br>with HTTPS OP endpoints, and if your RP has an https:// return_to address,<br>then you're already golden. The authenticating user will have the<br>
opportunity to see the information flash by in transit, but no one else<br>will, and presumably this information isn't to be held private against the<br>user himself! :)<br><br>On Sun, Aug 3, 2008 at 11:51 AM, SitG Admin <<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a><br>
> wrote:<br><br>> >I'd like to transmit sensitive data over the Attribute Exchange<br>> >Extension and was wondering about the best way for encryption.<br>><br>> Could you use the nonce for encryption? I assume here, of course,<br>
> that the nonce has already been encrypted during the OpenID exchange<br>> (I'm not strong on the technical aspects of this).<br>><br>> -Shade<br>> _______________________________________________<br>> general mailing list<br>
> <a href="mailto:general@openid.net">general@openid.net</a><br>> <a href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a><br>><br>-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>URL: <a href="http://openid.net/pipermail/general/attachments/20080803/2618a64b/attachment-0001.htm">http://openid.net/pipermail/general/attachments/20080803/2618a64b/attachment-0001.htm</a><br>
<br>------------------------------<br><br>Message: 5<br>Date: Sun, 3 Aug 2008 14:47:34 -0700<br>From: "Andrew Arnott" <<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>><br>Subject: Re: [OpenID] Secure attribute transmission<br>
To: "Johnny Bufu" <<a href="mailto:johnny.bufu@gmail.com">johnny.bufu@gmail.com</a>><br>Cc: OpenID List <<a href="mailto:general@openid.net">general@openid.net</a>>, <a href="mailto:Easysurfer@gmx.de">Easysurfer@gmx.de</a><br>
Message-ID:<br> <<a href="mailto:216e54900808031447s6c56138dr45cdf0a6641c60ff@mail.gmail.com">216e54900808031447s6c56138dr45cdf0a6641c60ff@mail.gmail.com</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br>
<br>Reusing the association secret and encrypting attribute values using that as<br>a shared key is an interesting possibility. It's not in any of the specs,<br>however, and I've heard some in the OpenID community look down on<br>
'overloading' an association. But it certainly sounds possible.<br><br>On Sun, Aug 3, 2008 at 2:17 PM, Johnny Bufu <<a href="mailto:johnny.bufu@gmail.com">johnny.bufu@gmail.com</a>> wrote:<br><br>><br>><br>
> On 03/08/08 11:27 AM, <a href="mailto:Easysurfer@gmx.de">Easysurfer@gmx.de</a> wrote:<br>> > I'd like to transmit sensitive data over the Attribute Exchange Extension<br>> and was wondering about the best way for encryption.<br>
> [...]<br>> > Any ideas? I'd like to pass the info over using only the OpenID<br>> > protocol, not invent another protocol for my own use.<br>><br>> If what you're trying to avoid is the exchange of another secret key<br>
> (and not require the RP to offer a HTTPS endpoint), then your only<br>> option is to enforce statefull mode and use the shared association<br>> secret to encrypt the attributes.<br>><br>> Otherwise, the exchange of the encryption key can be done through<br>
> attribute exchange. Working with the same assumption that RPs can't<br>> generally afford HTTPS endpoints, the key exchange would have to be<br>> initiated by the RP against a HTTPS OP endpoint, e.g. through a AX store<br>
> request.<br>><br>><br>> Johnny<br>><br>> _______________________________________________<br>> general mailing list<br>> <a href="mailto:general@openid.net">general@openid.net</a><br>> <a href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a><br>
><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <a href="http://openid.net/pipermail/general/attachments/20080803/2a7c8ef8/attachment-0001.htm">http://openid.net/pipermail/general/attachments/20080803/2a7c8ef8/attachment-0001.htm</a><br>
<br>------------------------------<br><br>Message: 6<br>Date: Sun, 3 Aug 2008 14:49:51 -0700<br>From: Peter Williams <<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>><br>Subject: Re: [OpenID] Secure attribute transmission<br>
To: Johnny Bufu <<a href="mailto:johnny.bufu@gmail.com">johnny.bufu@gmail.com</a>>, "<a href="mailto:Easysurfer@gmx.de">Easysurfer@gmx.de</a>"<br> <<a href="mailto:Easysurfer@gmx.de">Easysurfer@gmx.de</a>><br>
Cc: OpenID List <<a href="mailto:general@openid.net">general@openid.net</a>><br>Message-ID:<br> <<a href="mailto:7FD5B754D66D9A489C584ECA4B32418F1CA58C05@simmbox01.rapnt.com">7FD5B754D66D9A489C584ECA4B32418F1CA58C05@simmbox01.rapnt.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br><br>If the rp cannot "afford https", view this as a sign you don't want to be using that site for anything sensitive. Sensitive these days includes your friends list.<br>
<br>If a rp site is claiming excellence in its online features, but cannot afford https outlay, again their story is not hanging together. Audit red flag.<br><br>If a rp has spent money on implementing or integrating openid2 (which involves using https, in reality, to the xri proxy) and does not offer https as a rp, worry. The audit red flags are really up: their story is inconsistent.<br>
<br>Self signed certs for https are trivially easy to turn on: costing nothing, tho have adoption hassles similar to ssh2. Annual expenses to easily get around these issues are down to 25 euros (less than the cost of 1 starbucks coffee, a month).<br>
<br>A site that cannot afford those euro outlays may not be sufficienty financial sound ... to uphold the commodity security posture expected by global consumers, these days.<br><br>A site that prefers do design of an adhoc channel encryption protocol rather than use the well-reviewed handshake of ssl is also "somewhat" worrying. Normally, rookie crypto designers make the same or probably more crypto errors during handshake design as did the ssl designers, initially (and they had years and years of academic crypto experience!).<br>
<br>(i ran the "secrity review" policy at verisign for a while, requiring vendors licensing verisign trust points to engage a firm to do a pretty cursory inspection of their use of the ssl library. Guess what? The same implementation errors would occur over and over again, potentially degrading the trustworthiness of the verisign brand. After a few years, the "basic/noddy" design/implementation error rate stabilized, once certain flaw categories became widely understood. At that point, we let more conventional assurance programs take over, when guaging trustworthiness and assurance levels.)<br>
<br>-----Original Message-----<br>From: Johnny Bufu <<a href="mailto:johnny.bufu@gmail.com">johnny.bufu@gmail.com</a>><br>Sent: Sunday, August 03, 2008 2:17 PM<br>To: <a href="mailto:Easysurfer@gmx.de">Easysurfer@gmx.de</a> <<a href="mailto:Easysurfer@gmx.de">Easysurfer@gmx.de</a>><br>
Cc: OpenID List <<a href="mailto:general@openid.net">general@openid.net</a>><br>Subject: Re: [OpenID] Secure attribute transmission<br><br><br>On 03/08/08 11:27 AM, <a href="mailto:Easysurfer@gmx.de">Easysurfer@gmx.de</a> wrote:<br>
> I'd like to transmit sensitive data over the Attribute Exchange Extension and was wondering about the best way for encryption.<br>[...]<br>> Any ideas? I'd like to pass the info over using only the OpenID<br>
> protocol, not invent another protocol for my own use.<br><br>If what you're trying to avoid is the exchange of another secret key<br>(and not require the RP to offer a HTTPS endpoint), then your only<br>option is to enforce statefull mode and use the shared association<br>
secret to encrypt the attributes.<br><br>Otherwise, the exchange of the encryption key can be done through<br>attribute exchange. Working with the same assumption that RPs can't<br>generally afford HTTPS endpoints, the key exchange would have to be<br>
initiated by the RP against a HTTPS OP endpoint, e.g. through a AX store<br>request.<br><br><br>Johnny<br><br>_______________________________________________<br>general mailing list<br><a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a><br><br><br>------------------------------<br><br>Message: 7<br>Date: Sun, 3 Aug 2008 22:10:35 +0000<br>From: Nate Klingenstein <<a href="mailto:ndk@internet2.edu">ndk@internet2.edu</a>><br>
Subject: Re: [OpenID] Secure attribute transmission<br>To: "Andrew Arnott" <<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>><br>Cc: <a href="mailto:general@openid.net">general@openid.net</a><br>
Message-ID: <<a href="mailto:9905CF92-94AD-493D-A3F6-CCB9190CBD58@internet2.edu">9905CF92-94AD-493D-A3F6-CCB9190CBD58@internet2.edu</a>><br>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed<br><br>
Andrew,<br><br>I agree with you in general, but you might face resistance.<br><br>We've faced this issue in Shibboleth for a long time because SAML 1.1<br>has no encryption of the payload. As a result, we faced two<br>
choices. We could ship nothing particularly valuable in the payload<br>and do a back-channel call for attributes, which was generally via<br>mutually authenticated TLS(we have to be careful whom we released<br>student information to). The alternative was to "push" the<br>
attributes through the browser without encryption. There was TLS/SSL<br>used on both legs of the journey. Attribute push still encountered<br>strong resistance for two reasons.<br><br>1) The user can see all their attributes. I don't consider this a<br>
significant problem, but a few minor use cases may require<br>confidentiality between providers.<br>2) The user's spyware -- and many users have plenty of it -- can see<br>all the user's attributes too. Harvesting attributes is trivially<br>
automated and fun for all ages. This is, of course, a very large<br>problem, and often ends discussions immediately.<br><br>#2 was sufficient for almost everyone to avoid attribute push,<br>despite also having major problems with the setup of mutually<br>
authenticated TLS. We now default to attribute push in SAML 2.0, but<br>would probably have to revert back to the callback method.<br><br>Take care,<br>Nate.<br><br><br>On 3 Aug 2008, at 21:45, Andrew Arnott wrote:<br><br>
> The openid.response_nonce won't be helpful here. If your RP can<br>> work only with HTTPS OP endpoints, and if your RP has an https://<br>> return_to address, then you're already golden. The authenticating<br>
> user will have the opportunity to see the information flash by in<br>> transit, but no one else will, and presumably this information<br>> isn't to be held private against the user himself! :)<br><br><br><br>
------------------------------<br><br>Message: 8<br>Date: Sun, 3 Aug 2008 22:15:17 +0000<br>From: Nate Klingenstein <<a href="mailto:ndk@internet2.edu">ndk@internet2.edu</a>><br>Subject: Re: [OpenID] Secure attribute transmission<br>
To: Nate Klingenstein <<a href="mailto:ndk@internet2.edu">ndk@internet2.edu</a>><br>Cc: <a href="mailto:general@openid.net">general@openid.net</a><br>Message-ID: <<a href="mailto:5672CDC0-D549-448F-B231-D5C499BA7F70@internet2.edu">5672CDC0-D549-448F-B231-D5C499BA7F70@internet2.edu</a>><br>
Content-Type: text/plain; charset="us-ascii"<br><br>Just to be clear, we default to attribute push in 2.0 because it has<br>encryption, and we'd have to revert back to the callback method if we<br>used a protocol that couldn't encrypt payloads.<br>
<br>On 3 Aug 2008, at 22:10, Nate Klingenstein wrote:<br><br>> We now default to attribute push in SAML 2.0, but<br>> would probably have to revert back to the callback method.<br><br>-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>URL: <a href="http://openid.net/pipermail/general/attachments/20080803/52411671/attachment.htm">http://openid.net/pipermail/general/attachments/20080803/52411671/attachment.htm</a><br>
<br>------------------------------<br><br>_______________________________________________<br>general mailing list<br><a href="mailto:general@openid.net">general@openid.net</a><br><a href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a><br>
<br><br>End of general Digest, Vol 24, Issue 10<br>***************************************<br></blockquote></div><br>