[OpenID] general Digest, Vol 24, Issue 10
prakash jha
prksh.jha at gmail.com
Mon Aug 4 13:49:34 UTC 2008
sir, i want start feedback their mobile, so i request please solve my
problem
thank you
On 8/4/08, general-request at openid.net <general-request at openid.net> wrote:
>
> Send general mailing list submissions to
> general at openid.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://openid.net/mailman/listinfo/general
> or, via email, send a message with subject or body 'help' to
> general-request at openid.net
>
> You can reach the person managing the list at
> general-owner at openid.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of general digest..."
>
>
> Today's Topics:
>
> 1. Re: OpenID'09 Program Launch - You are all invited to
> participate! (SitG Admin)
> 2. Re: Musing on FaceBook, OpenID and the next mountain to
> climb (Johnny Bufu)
> 3. Re: Secure attribute transmission (Johnny Bufu)
> 4. Re: Secure attribute transmission (Andrew Arnott)
> 5. Re: Secure attribute transmission (Andrew Arnott)
> 6. Re: Secure attribute transmission (Peter Williams)
> 7. Re: Secure attribute transmission (Nate Klingenstein)
> 8. Re: Secure attribute transmission (Nate Klingenstein)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 3 Aug 2008 12:05:12 -0700
> From: SitG Admin <sysadmin at shadowsinthegarden.com>
> Subject: Re: [OpenID] OpenID'09 Program Launch - You are all invited
> to participate!
> To: "Julian Granger-Bevan" <julian.granger-bevan at magnity.co.uk
> >, tom
> <tom at barnraiser.org>
> Cc: general at openid.net
> Message-ID: <f06110403c4bbaee6f9ac@[192.168.0.2]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>
> At 2:39 PM +0200 8/3/08, tom wrote:
> >You mention that discussions on list are often not picked up and I
> >agree, but I think that is because of the lack of focal area that the
>
> I think that another reason could be the transient nature of E-mail;
> once posted, soon forgotten? Or not, but my point is that it's easy
> to lose track of messages, and as the community grows (and, along
> with it, the rate of discussion on this list), it'll be more and more
> difficult to go back through the archives looking for particular
> discussions. This is even harder if you weren't around to receive the
> E-mail's back then!
>
> As another solution (in addition to your proposal), I'd like to see
> an area of either wiki (openid.net or OpenID'09) devoted to keeping
> track of which informative or potentially useful messages have been
> posted to the archives, and linking back to them. That way,
> interested parties could quickly find what they were looking for; or,
> simply browse through old ideas and solutions waiting for their
> problems ;)
>
> At 11:26 AM +0100 8/3/08, Julian Granger-Bevan wrote:
> >Surely it will help most if all of the information for the site is
> >situated within the one main domain.
>
> I think the idea here was to separate information that was intended
> for general consumption, from information aimed more at the
> Foundation/Community; this can reduce confusion in the average user
> who visits openid.net just trying to learn what this is all about.
>
> -Shade
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 03 Aug 2008 14:08:36 -0700
> From: Johnny Bufu <johnny.bufu at gmail.com>
> Subject: Re: [OpenID] Musing on FaceBook, OpenID and the next mountain
> to climb
> To: Eran Hammer-Lahav <eran at hueniverse.com>
> Cc: OpenID <general at openid.net>
> Message-ID: <48961E54.9090405 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> On 02/08/08 03:00 PM, Eran Hammer-Lahav wrote:
> > My comments were specific about the technical details of their platform.
> > The fact that instead of using a community specification they decided to
> > create yet another protocol is what I was referring to. I would give
> > them a high score if they used OAuth but still kept their system closed
> > and data private. They could have created the exact same product by
> > building it on top of OAuth. They could have also made it friendlier to
> > OpenID or even use OpenID as the basis but I think OAuth would have been
> > an easier match and lighter on the politics.
>
> I would be interested to learn directly from Facebook what their high
> level requirements were and why they chose not to use OAuth/OpenID.
>
> Since I haven't seen anyone from Facebook commenting on the openid
> general list, what channels would they prefer? Dick, do you have any
> insights here?
>
>
> Johnny
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 03 Aug 2008 14:17:04 -0700
> From: Johnny Bufu <johnny.bufu at gmail.com>
> Subject: Re: [OpenID] Secure attribute transmission
> To: Easysurfer at gmx.de
> Cc: OpenID List <general at openid.net>
> Message-ID: <48962050.9060908 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
>
> On 03/08/08 11:27 AM, Easysurfer at gmx.de wrote:
> > I'd like to transmit sensitive data over the Attribute Exchange Extension
> and was wondering about the best way for encryption.
> [...]
> > Any ideas? I'd like to pass the info over using only the OpenID
> > protocol, not invent another protocol for my own use.
>
> If what you're trying to avoid is the exchange of another secret key
> (and not require the RP to offer a HTTPS endpoint), then your only
> option is to enforce statefull mode and use the shared association
> secret to encrypt the attributes.
>
> Otherwise, the exchange of the encryption key can be done through
> attribute exchange. Working with the same assumption that RPs can't
> generally afford HTTPS endpoints, the key exchange would have to be
> initiated by the RP against a HTTPS OP endpoint, e.g. through a AX store
> request.
>
>
> Johnny
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 3 Aug 2008 14:45:53 -0700
> From: "Andrew Arnott" <andrewarnott at gmail.com>
> Subject: Re: [OpenID] Secure attribute transmission
> To: "SitG Admin" <sysadmin at shadowsinthegarden.com>
> Cc: general at openid.net, Easysurfer at gmx.de
> Message-ID:
> <216e54900808031445w47c42ad2gc6329f2d941e65a at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> The openid.response_nonce won't be helpful here. If your RP can work only
> with HTTPS OP endpoints, and if your RP has an https:// return_to address,
> then you're already golden. The authenticating user will have the
> opportunity to see the information flash by in transit, but no one else
> will, and presumably this information isn't to be held private against the
> user himself! :)
>
> On Sun, Aug 3, 2008 at 11:51 AM, SitG Admin <
> sysadmin at shadowsinthegarden.com
> > wrote:
>
> > >I'd like to transmit sensitive data over the Attribute Exchange
> > >Extension and was wondering about the best way for encryption.
> >
> > Could you use the nonce for encryption? I assume here, of course,
> > that the nonce has already been encrypted during the OpenID exchange
> > (I'm not strong on the technical aspects of this).
> >
> > -Shade
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://openid.net/pipermail/general/attachments/20080803/2618a64b/attachment-0001.htm
>
> ------------------------------
>
> Message: 5
> Date: Sun, 3 Aug 2008 14:47:34 -0700
> From: "Andrew Arnott" <andrewarnott at gmail.com>
> Subject: Re: [OpenID] Secure attribute transmission
> To: "Johnny Bufu" <johnny.bufu at gmail.com>
> Cc: OpenID List <general at openid.net>, Easysurfer at gmx.de
> Message-ID:
> <216e54900808031447s6c56138dr45cdf0a6641c60ff at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Reusing the association secret and encrypting attribute values using that
> as
> a shared key is an interesting possibility. It's not in any of the specs,
> however, and I've heard some in the OpenID community look down on
> 'overloading' an association. But it certainly sounds possible.
>
> On Sun, Aug 3, 2008 at 2:17 PM, Johnny Bufu <johnny.bufu at gmail.com> wrote:
>
> >
> >
> > On 03/08/08 11:27 AM, Easysurfer at gmx.de wrote:
> > > I'd like to transmit sensitive data over the Attribute Exchange
> Extension
> > and was wondering about the best way for encryption.
> > [...]
> > > Any ideas? I'd like to pass the info over using only the OpenID
> > > protocol, not invent another protocol for my own use.
> >
> > If what you're trying to avoid is the exchange of another secret key
> > (and not require the RP to offer a HTTPS endpoint), then your only
> > option is to enforce statefull mode and use the shared association
> > secret to encrypt the attributes.
> >
> > Otherwise, the exchange of the encryption key can be done through
> > attribute exchange. Working with the same assumption that RPs can't
> > generally afford HTTPS endpoints, the key exchange would have to be
> > initiated by the RP against a HTTPS OP endpoint, e.g. through a AX store
> > request.
> >
> >
> > Johnny
> >
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://openid.net/pipermail/general/attachments/20080803/2a7c8ef8/attachment-0001.htm
>
> ------------------------------
>
> Message: 6
> Date: Sun, 3 Aug 2008 14:49:51 -0700
> From: Peter Williams <pwilliams at rapattoni.com>
> Subject: Re: [OpenID] Secure attribute transmission
> To: Johnny Bufu <johnny.bufu at gmail.com>, "Easysurfer at gmx.de"
> <Easysurfer at gmx.de>
> Cc: OpenID List <general at openid.net>
> Message-ID:
> <7FD5B754D66D9A489C584ECA4B32418F1CA58C05 at simmbox01.rapnt.com>
> Content-Type: text/plain; charset="us-ascii"
>
> 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.
>
> 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.
>
> 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.
>
> 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).
>
> 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.
>
> 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!).
>
> (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.)
>
> -----Original Message-----
> From: Johnny Bufu <johnny.bufu at gmail.com>
> Sent: Sunday, August 03, 2008 2:17 PM
> To: Easysurfer at gmx.de <Easysurfer at gmx.de>
> Cc: OpenID List <general at openid.net>
> Subject: Re: [OpenID] Secure attribute transmission
>
>
> On 03/08/08 11:27 AM, Easysurfer at gmx.de wrote:
> > I'd like to transmit sensitive data over the Attribute Exchange Extension
> and was wondering about the best way for encryption.
> [...]
> > Any ideas? I'd like to pass the info over using only the OpenID
> > protocol, not invent another protocol for my own use.
>
> If what you're trying to avoid is the exchange of another secret key
> (and not require the RP to offer a HTTPS endpoint), then your only
> option is to enforce statefull mode and use the shared association
> secret to encrypt the attributes.
>
> Otherwise, the exchange of the encryption key can be done through
> attribute exchange. Working with the same assumption that RPs can't
> generally afford HTTPS endpoints, the key exchange would have to be
> initiated by the RP against a HTTPS OP endpoint, e.g. through a AX store
> request.
>
>
> Johnny
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 3 Aug 2008 22:10:35 +0000
> From: Nate Klingenstein <ndk at internet2.edu>
> Subject: Re: [OpenID] Secure attribute transmission
> To: "Andrew Arnott" <andrewarnott at gmail.com>
> Cc: general at openid.net
> Message-ID: <9905CF92-94AD-493D-A3F6-CCB9190CBD58 at internet2.edu>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> Andrew,
>
> I agree with you in general, but you might face resistance.
>
> We've faced this issue in Shibboleth for a long time because SAML 1.1
> has no encryption of the payload. As a result, we faced two
> choices. We could ship nothing particularly valuable in the payload
> and do a back-channel call for attributes, which was generally via
> mutually authenticated TLS(we have to be careful whom we released
> student information to). The alternative was to "push" the
> attributes through the browser without encryption. There was TLS/SSL
> used on both legs of the journey. Attribute push still encountered
> strong resistance for two reasons.
>
> 1) The user can see all their attributes. I don't consider this a
> significant problem, but a few minor use cases may require
> confidentiality between providers.
> 2) The user's spyware -- and many users have plenty of it -- can see
> all the user's attributes too. Harvesting attributes is trivially
> automated and fun for all ages. This is, of course, a very large
> problem, and often ends discussions immediately.
>
> #2 was sufficient for almost everyone to avoid attribute push,
> despite also having major problems with the setup of mutually
> authenticated TLS. We now default to attribute push in SAML 2.0, but
> would probably have to revert back to the callback method.
>
> Take care,
> Nate.
>
>
> On 3 Aug 2008, at 21:45, Andrew Arnott wrote:
>
> > The openid.response_nonce won't be helpful here. If your RP can
> > work only with HTTPS OP endpoints, and if your RP has an https://
> > return_to address, then you're already golden. The authenticating
> > user will have the opportunity to see the information flash by in
> > transit, but no one else will, and presumably this information
> > isn't to be held private against the user himself! :)
>
>
>
> ------------------------------
>
> Message: 8
> Date: Sun, 3 Aug 2008 22:15:17 +0000
> From: Nate Klingenstein <ndk at internet2.edu>
> Subject: Re: [OpenID] Secure attribute transmission
> To: Nate Klingenstein <ndk at internet2.edu>
> Cc: general at openid.net
> Message-ID: <5672CDC0-D549-448F-B231-D5C499BA7F70 at internet2.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> Just to be clear, we default to attribute push in 2.0 because it has
> encryption, and we'd have to revert back to the callback method if we
> used a protocol that couldn't encrypt payloads.
>
> On 3 Aug 2008, at 22:10, Nate Klingenstein wrote:
>
> > We now default to attribute push in SAML 2.0, but
> > would probably have to revert back to the callback method.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://openid.net/pipermail/general/attachments/20080803/52411671/attachment.htm
>
> ------------------------------
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
> End of general Digest, Vol 24, Issue 10
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080804/fe348d99/attachment-0002.htm>
More information about the general
mailing list