IRC Log for #openid on 2009-05-16

Timestamps are in UTC.

  1. [00:03:27] * mosites (n=mosites@udp008530uds.hawaiiantel.net) has joined #openid
  2. [00:41:55] * daleolds (n=daleolds@c-76-27-115-77.hsd1.ut.comcast.net) has joined #openid
  3. [01:06:49] * benblack (n=bb@dsl254-017-242.sea1.dsl.speakeasy.net) has joined #openid
  4. [01:15:57] * daleolds (n=daleolds@c-76-27-115-77.hsd1.ut.comcast.net) has left #openid
  5. [02:28:26] * singpolyma (n=singpoly@173-11-94-130-SFBA.hfc.comcastbusiness.net) Quit ("Lost terminal")
  6. [02:31:17] * jcollie (n=jcollie@fedora/jcollie) Quit (Read error: 104 (Connection reset by peer))
  7. [02:32:10] * mosites (n=mosites@udp008530uds.hawaiiantel.net) Quit ()
  8. [02:33:12] * elliottcable (n=ec@ec2-75-101-138-129.compute-1.amazonaws.com) Quit ("leaving")
  9. [02:33:27] * elliottcable (n=ec@ec2-75-101-138-129.compute-1.amazonaws.com) has joined #OpenID
  10. [02:35:11] * jcollie (n=jcollie@fedora/jcollie) has joined #openid
  11. [02:49:07] * singpolyma (n=singpoly@c-76-21-5-96.hsd1.ca.comcast.net) has joined #openid
  12. [05:07:45] * mosites (n=mosites@udp008530uds.hawaiiantel.net) has joined #openid
  13. [05:13:58] * mosites (n=mosites@udp008530uds.hawaiiantel.net) Quit ()
  14. [05:25:54] * metadaddy (n=metadadd@c-76-102-134-32.hsd1.ca.comcast.net) Quit ()
  15. [05:34:47] * MacTed (n=Thud@twentyfourmullen.hsd1.ma.comcast.net) Quit ()
  16. [07:17:01] * singpolyma (n=singpoly@c-76-21-5-96.hsd1.ca.comcast.net) Quit ("Lost terminal")
  17. [07:31:18] * mosites (n=mosites@udp008530uds.hawaiiantel.net) has joined #openid
  18. [07:50:48] * mosites (n=mosites@udp008530uds.hawaiiantel.net) Quit ()
  19. [08:02:17] * fizk (n=yonas@CPE001a706e7734-CM00111ade9e1c.cpe.net.cable.rogers.com) has joined #openid
  20. [08:02:28] <fizk> hi
  21. [08:02:34] <fizk> anyone alive
  22. [08:56:18] * daedeloth (n=daedelot@ip-81-11-183-64.dsl.scarlet.be) has joined #openid
  23. [09:11:27] * daedeloth (n=daedelot@ip-81-11-183-64.dsl.scarlet.be) Quit (Remote closed the connection)
  24. [09:16:41] * xpo (n=xpo@bearstech/xpo) has joined #openid
  25. [09:16:56] * daedeloth (n=daedelot@ip-81-11-183-64.dsl.scarlet.be) has joined #openid
  26. [09:25:12] * xpo (n=xpo@bearstech/xpo) Quit ()
  27. [09:35:22] * mosites (n=mosites@udp008530uds.hawaiiantel.net) has joined #openid
  28. [09:36:26] * mosites (n=mosites@udp008530uds.hawaiiantel.net) has left #openid
  29. [10:16:50] * xpo (n=xpo@bearstech/xpo) has joined #openid
  30. [11:27:35] * josephholsten (n=josephho@ip68-0-70-106.tu.ok.cox.net) has joined #openid
  31. [11:31:27] <fizk> hello?
  32. [11:36:24] <josephholsten> hi there
  33. [12:04:00] <fizk> hey josephholsten
  34. [12:04:13] <fizk> i'm looking into enabling OpenID for IRC
  35. [12:04:29] <fizk> my first idea went something like this:
  36. [12:05:45] <fizk> http://pastebin.com/d5e666c30
  37. [12:07:24] <fizk> I looked at libopkele for a C++ implementation on the IRC server and client
  38. [12:08:32] <fizk> after more thinking, I believe this should be easily done by using libopkele on the server and client, and adding a new requirement to OpenID spec
  39. [12:10:33] <fizk> the change would require the OP to send an standard login XML file
  40. [12:10:46] <fizk> so that that client software can parse and submit it
  41. [12:11:02] <fizk> so a "login-by-XML" extension
  42. [12:11:25] <fizk> still there josephholsten?
  43. [12:11:46] <josephholsten> oops, hello again
  44. [12:11:54] <fizk> wb
  45. [12:12:41] <josephholsten> interesting
  46. [12:13:45] <fizk> the extension could say something like, if the "login-by-xml" extension has been requested, either include the XML document as part of the normal HTML page, or as a separate URL
  47. [12:13:55] <fizk> i'm very suprised that this doesn't exist already
  48. [12:14:00] <fizk> *surprised
  49. [12:14:23] <josephholsten> I guess I don't understand
  50. [12:14:33] <fizk> np, which part?
  51. [12:15:30] <josephholsten> why don't we walk through the normal flow
  52. [12:15:54] <josephholsten> alice hands bob a uri
  53. [12:15:56] <fizk> k
  54. [12:16:47] <josephholsten> bob requests the resource, finds OP endpoint
  55. [12:18:14] <fizk> yup
  56. [12:18:17] <josephholsten> oops, was staring at 1.1
  57. [12:18:29] <josephholsten> no point in extending that
  58. [12:20:15] <josephholsten> bob sends an association req to charlie, the OP
  59. [12:21:55] <josephholsten> or not, but bob must send a authn req to charlie
  60. [12:22:56] <josephholsten> I'm sorry, I've been looking at oauth too much, I'm getting them confused
  61. [12:24:18] <fizk> I'm about to paste 8 lines here
  62. [12:24:22] <fizk> do u want pastebin instead?
  63. [12:24:32] <josephholsten> go ahead
  64. [12:24:47] <fizk> 1 sec
  65. [12:24:56] <josephholsten> I'm reviewing the diagram at http://leancode.com/2007/02/23/openid-protocol-diagram/
  66. [12:25:34] <josephholsten> charlie and bob create a shared secret
  67. [12:26:11] <fizk> 1. IRC Client: /openid register foobar@yahoo.com mypassword
  68. [12:26:11] <fizk> 2. IRC Client sends message to IRC Server
  69. [12:26:11] <fizk> "I'd like to begin an openid login, OP: yahoo.com"
  70. [12:26:11] <fizk> 3. IRC server creates a OpenID request
  71. [12:26:11] <fizk> 4. IRC server sends request URL to IRC Client
  72. [12:26:12] <fizk> 5. IRC Client fetchs Login-via-XML document
  73. [12:26:14] <fizk> 6. IRC Client submits XML response document, containing username:foobar password:mypassword
  74. [12:26:16] <fizk> 7. Yahoo sends back OpenID success response
  75. [12:26:18] <fizk> 8. IRC Client sends message to IRC Server
  76. [12:26:20] <fizk> "This is the response information'
  77. [12:26:22] <fizk> 9. IRC Server uses the information to confirm/verifies that the login was successful
  78. [12:26:24] <fizk> 10. IRC Server now recognizes the user as foobar@yahoo.com
  79. [12:30:21] <fizk> what do you think?
  80. [12:30:44] * fizk is now known as yonas
  81. [12:30:55] <josephholsten> sounds fair, you're saying you want the authentication response in XML
  82. [12:31:04] <josephholsten> the one from here: http://openid.net/specs/openid-authentication-2_0.html#responding_to_authentication
  83. [12:31:18] <josephholsten> what I don't get is why
  84. [12:33:12] <josephholsten> would you have the rest of the messages use the normal encoding?
  85. [12:33:47] <yonas> normal encoding?
  86. [12:34:07] <yonas> everything about the spec would be the same except the Login-via-XML part
  87. [12:35:01] <josephholsten> yeah, the key-value encoding: http://openid.net/specs/openid-authentication-2_0.html#kvform
  88. [12:35:31] <yonas> yea, that would be the same
  89. [12:36:22] <yonas> if Login-via-XML is implemented, many non-browser apps can take advantage
  90. [12:36:54] <josephholsten> I don't understand. are you talking about an existing xml format for assertions, like SAML?
  91. [12:37:35] <josephholsten> also, browsers don't really matter
  92. [12:37:50] <josephholsten> unless your OP remembers you with a cookie
  93. [12:39:59] <yonas> i just read about SAML on wikipedia, and it could be used for Login-via-XML.
  94. [12:40:08] <yonas> Basically, the XML document would be standard
  95. [12:40:12] <josephholsten> right, it could be, but why?
  96. [12:40:35] <josephholsten> the key-value form is standard
  97. [12:40:46] <yonas> is it?
  98. [12:41:10] <josephholsten> would you consider openid standard?
  99. [12:41:23] <yonas> yea
  100. [12:41:37] <yonas> RTF and all that :)
  101. [12:41:54] <josephholsten> the key-value form is defined as part of the openid standard
  102. [12:42:14] <josephholsten> don't get me wrong, I wish they'd used rfc822 or something
  103. [12:42:22] <yonas> where? i read that this was out of scope
  104. [12:42:44] <josephholsten> http://openid.net/specs/openid-authentication-2_0.html#kvform
  105. [12:42:51] <josephholsten> OOOOoooh
  106. [12:42:52] <yonas> The OP establishes whether the end user is authorized to perform OpenID Authentication and wishes to do so. The manner in which the end user authenticates to their OP and any policies surrounding such authentication is out of scope for this document.
  107. [12:43:05] <josephholsten> right then
  108. [12:43:23] <josephholsten> sorry, minor misunderstanding
  109. [12:43:27] <yonas> np
  110. [12:44:12] <josephholsten> yeah, for the IRC client to authenticate with the OP, I'd either use HTTP basic/digest or SSL client certs
  111. [12:44:42] <josephholsten> myopenid allows ssl client certs now
  112. [12:44:48] <yonas> but how would you know which form fields to fill out
  113. [12:44:53] <yonas> if it's not standard?
  114. [12:45:26] <yonas> yahoo might use <form><input name="login1" /></form>
  115. [12:45:29] <josephholsten> ssl client certs don't need form fields
  116. [12:45:47] <yonas> myopenid might use ...<input name="login2">
  117. [12:46:03] <yonas> hm
  118. [12:47:15] <yonas> ssl client certs aren't as convenient....you need to have it on the machine you are on
  119. [12:47:16] <yonas> no?
  120. [12:48:07] <yonas> ssl client certs could be used as another login standard
  121. [12:48:07] <josephholsten> you just submit a request to the OP endpoint, it works like a cookie
  122. [12:49:01] <yonas> is it part of the openid standard?
  123. [12:49:05] <josephholsten> if you can't depend on having credentials stored on the machine, you'd be stuck with something like standard http auth
  124. [12:49:20] <josephholsten> neither are part of the standard
  125. [12:49:48] <yonas> if you have Login-via-XML, you could retrieve and submit via SSL
  126. [12:49:58] <josephholsten> you're right, it's out of scope
  127. [12:51:38] <yonas> we could make it an extension though
  128. [12:51:52] <josephholsten> yes, I quite agree
  129. [12:52:03] <yonas> the user should be able to say, "i want to use the extension: login-via-xml"
  130. [12:52:18] * qwp0 (n=qwp0@gw.localnet.sk) has joined #openid
  131. [12:52:31] <josephholsten> ok, I see two main cases: 1) machine already has a credential set up with the OP, and some OPs are using SSL client certs for that, and 2) machine doesn't already have a credential, so the user has to have some verifiable info
  132. [12:52:49] <josephholsten> in the second case, that's usually a username/password
  133. [12:53:20] <yonas> k
  134. [12:53:39] <josephholsten> since you probably can't depend on scraping an HTML form for the right field names
  135. [12:53:51] <yonas> exactly
  136. [12:53:59] <yonas> that'd be a joke
  137. [12:54:02] <josephholsten> you need a standard way of sending the username and password
  138. [12:54:54] <yonas> yup
  139. [12:55:04] <josephholsten> it is a joke, but 1password, vidoop, and sxipper have pretty good solutions for that awfully painful situation
  140. [12:55:13] <josephholsten> anyway, there is a standard
  141. [12:55:38] <josephholsten> http://www.ietf.org/rfc/rfc2617.txt
  142. [12:59:23] <yonas> hm
  143. [13:01:15] <yonas> ok, so the IRC Client should be able to say, "i'd like to login via rfc2617"
  144. [13:01:59] <josephholsten> yes
  145. [13:02:09] <yonas> the IRC Client sends username/password, and gets back the OpenID response
  146. [13:03:15] <yonas> this ability isn't in the standard, can we add it?
  147. [13:03:58] <josephholsten> yes and no
  148. [13:05:08] <josephholsten> check out http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html
  149. [13:06:18] <josephholsten> oOo, esp: http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html#anchor12
  150. [13:07:28] <josephholsten> I think you'll find most OPs would be okay with HTTP basic
  151. [13:09:05] <josephholsten> but obviously it can't compete with NIST level 4 authentication
  152. [13:10:56] <yonas> almost everyone uses HTTP basic + SSL.....
  153. [13:14:57] <yonas> what I was really looking for was HMAC-SHA1 authentication via XML
  154. [13:15:14] <yonas> OpenID uses HMAC-SHA1/256
  155. [13:17:07] <josephholsten> you've always got xml-dsig
  156. [13:17:31] <yonas> it's very good to have that standard, so if we could just extend that to authenticate via XML, we're done
  157. [13:17:42] <josephholsten> http://www.w3.org/TR/xmldsig-core/
  158. [13:20:46] <yonas> very nice!
  159. [13:21:04] <josephholsten> so what, you're thinking:
  160. [13:21:17] <josephholsten> op passes user a nonce+timestamp
  161. [13:21:29] <yonas> so we should enforce HMAC-SHA1/256 for the XML doc
  162. [13:21:50] <yonas> yea
  163. [13:21:53] <yonas> and they sign that
  164. [13:22:11] <josephholsten> user generates a key from password, then sends back the signed(nonce+timestamp+username)
  165. [13:22:25] <yonas> send HMAC-SHA1( password, nonce+timestamp )
  166. [13:22:35] <yonas> hm
  167. [13:22:45] <yonas> yea
  168. [13:22:57] <yonas> the password would have to be the key, no?
  169. [13:23:09] <josephholsten> you may want to investigate HTTP digest
  170. [13:23:35] <josephholsten> put it this way: the user has to have a credential to generate a key
  171. [13:25:09] <josephholsten> you're basically doing public-key needham-shroeder: http://en.wikipedia.org/wiki/Needham-Schroeder
  172. [13:25:09] <yonas> ok
  173. [13:25:16] <yonas> lol
  174. [13:25:52] <yonas> you know a lot of standards my man :)
  175. [13:26:11] <josephholsten> of course, by including the timestamp, you solve one of its main weaknesses
  176. [13:26:24] <josephholsten> unfortunately, yes
  177. [13:27:07] <josephholsten> I'm trying to stop being such an asshole and become a better moron: http://diveintomark.org/archives/2004/08/16/specs
  178. [13:30:10] <josephholsten> actually, it's nothing like needham-schroeder
  179. [13:36:29] <yonas> I'm not sure if it's exactly what's needed here, but
  180. [13:36:54] <yonas> HMAC-SHA1( some key, username + timestamp + nonce ) is good
  181. [13:37:53] <josephholsten> yeah, I was confused because kerberos uses needham-shroeder with a password as the shared secret
  182. [13:38:09] <josephholsten> but you don't want another third party
  183. [13:38:38] <josephholsten> you basically just want a better version of HTTP digest: http://en.wikipedia.org/wiki/Digest_authentication
  184. [13:38:43] <josephholsten> I mean it this time
  185. [13:40:01] <yonas> yea, a better HTTP digest
  186. [13:40:45] <yonas> I like how OpenID restricts the algorithm, it makes it easy to implement
  187. [13:41:27] <josephholsten> HA1 is generated from username+pass, HA2 from the OP endpoint, and response from HA1+HA2+various nonces
  188. [13:41:57] <yonas> what's HA1
  189. [13:42:58] <josephholsten> part of how digest works
  190. [13:43:19] <yonas> ah
  191. [13:44:49] <yonas> alrighty
  192. [13:44:59] <yonas> so what's your final recommendation?
  193. [13:49:28] <yonas> thanks for all your help so far!!!!! :)
  194. [13:49:43] <josephholsten> checking out 2-legged OAuth with username as consumer_key and password as token
  195. [13:50:16] <josephholsten> I forgot the OpenID guys and the OAuth guys were hoping to unify the signature specs
  196. [13:54:25] <qwp0> topic #okrb
  197. [13:54:34] <qwp0> oops, sorry
  198. [13:56:11] <josephholsten> if you look at this, you'll see the username included as a query parameter. With oauth, the shared secret in the oauth_token is combined with the headers when the signature is computed, but not passed along with headers during the request
  199. [13:56:18] <josephholsten> http://code.google.com/apis/accounts/docs/OAuth.html#EnablingOAuth
  200. [13:56:37] <josephholsten> qwp0: you're an oklahoman too?
  201. [13:58:09] <josephholsten> hmm ehl has a different take on 2-legged oauth: http://www.hueniverse.com/hueniverse/2008/10/beginners-guide.html
  202. [13:58:19] <josephholsten> When OAuth is used as a direct replacement of HTTP 'Basic', the Consumer Key and Consumer Secret should hold the username and password, and the Token and Token Secret should remain empty.
  203. [14:00:13] * yonas is reading
  204. [14:11:33] <qwp0> josephholsten: nope, just was looking through topics of the channels you're on :)
  205. [14:12:56] <josephholsten> qwp0: if I weren't a hacker turned security freak, I might find that kinda wierd ; )
  206. [14:13:40] <yonas> ok, so from what i understand 2-legged OAuth is a good replacement for HTTP Basic: "Using OAuth for simple sign-in has the same user experience as HTTP 'Basic', but when used over an insecure channel OAuth provides much greater security."
  207. [14:14:07] <yonas> i've read about oauth when doing YouTube API programming
  208. [14:14:31] <yonas> like you said, it's not part of OpenID (yet?)
  209. [14:14:57] <qwp0> josephholsten: well, there are many interesting channels on Freenode I don't know of -- I'm just broadening my horizons ;)
  210. [14:16:44] <josephholsten> yonas: 2-legged OAuth is a great replacement for HTTP Basic, and a moderately improved replacement for HTTP Digest. And you'll be sure to hear more about OpenID+OAuth next week during IIW
  211. [14:19:18] <yonas> IIW ?
  212. [14:20:00] <josephholsten> yonas: OAuth depends on a predetermined shared secret (consumer key+secret), so it's inherently more powerful than secret-sharing like Diffie-Hellman, which OpenID uses. But if you can't negotiate a secret beforehand, you can't get at that power.
  213. [14:20:06] <yonas> so how might the combination enable OpenID on IRC?
  214. [14:20:46] <josephholsten> yonas: Internet Identity Workshop: http://iiw.idcommons.net/Main_Page
  215. [14:23:05] <yonas> interesting
  216. [14:23:54] <yonas> but I'm not sure how the combination would help enable OpenID on IRC
  217. [14:23:57] <josephholsten> you've got two tasks to solve to enable OpenID on IRC: have an Identity Provider assert the Client actually owns a URL (and whatever other profile data you want to send), and convince the Identity Provider that the Client is authentic
  218. [14:24:39] <josephholsten> OpenID is a tool for the first, but it leaves the second generally undefined
  219. [14:25:42] <josephholsten> right now, you'll usually do the second by logging into your Identity Provider (aka OpenID Provider or OP) with a username and password over HTTP+TLS
  220. [14:26:04] <josephholsten> or you'll pass the OP a cookie that you got earlier
  221. [14:27:54] <josephholsten> Some OPs are very picky, so you might use a X.509 client cert with TLS (myopenid), or you might use a one-time-password dongle to supply your password (verisign), or you might get out of band verification (vidoop)
  222. [14:28:32] <josephholsten> but the question for IRC clients is: what's the simplest thing that could possibly work?
  223. [14:29:06] <josephholsten> to which I say: HTTP Basic Authn over TLS
  224. [14:29:46] * xpo (n=xpo@bearstech/xpo) Quit ()
  225. [14:30:31] <josephholsten> but since that's clearly too simple: here's 2-legged oauth
  226. [14:31:40] <josephholsten> with oauth, you have different names for things, because what's the fun of creating a standard if you aren't going to define things differently from everyone else
  227. [14:32:20] <josephholsten> with OAuth, you've got a Service Provider (OP) and a Consumer (Client)
  228. [14:32:58] <josephholsten> (it's more complicated with normal three-legged, but we'll ignore that)
  229. [14:33:45] <josephholsten> the consumer and SP already negotiate a public consumer_key and private consumer_secret beforehand
  230. [14:33:57] <josephholsten> these are equivalent to a public username and private password
  231. [14:34:48] <josephholsten> When the consumer wants to send the SP a message, they tack on an Authentication header, similar to that used for HTTP Basic and Digest
  232. [14:36:16] <josephholsten> in the header is the public consumer_key, a nonce, a timestamp, a signature, and some metadata (oauth version, signature method)
  233. [14:36:35] <josephholsten> the nonce and timestamp have specific properties, which I will ignore
  234. [14:38:28] <josephholsten> the signature is created by using HMAC-SHA1(message) where message = {metadata, nonce, timestamp, consumer_key, _*consumer_secret*_}
  235. [14:40:21] <josephholsten> obviously the OP/IdP/SP knows the private/consumer_secret/password, so it can generate the message used to create the MAC
  236. [14:40:51] <josephholsten> it's HTTP Digest that's less broken
  237. [14:42:50] <josephholsten> clear as mud?
  238. [14:42:54] <yonas> lol
  239. [14:43:01] <yonas> hmm
  240. [14:48:41] <yonas> so oauth enables an user so say "this application can access my stuff"
  241. [14:49:27] <yonas> but i don't think we need that functionality here
  242. [14:49:51] <yonas> we just need identity confirmation
  243. [14:51:43] <yonas> I'm looking at this flow:
  244. [14:51:43] <yonas> http://oauth.net/core/1.0/
  245. [14:52:51] <josephholsten> yes, that's why I distinguished between two-legged and normal three-legged oauth
  246. [14:53:27] <josephholsten> assume you don't need to negotiate for tokens, they are blank
  247. [14:53:59] <josephholsten> and the user is the consumer
  248. [14:54:27] <yonas> so the IRC client is the consumer?
  249. [14:54:46] * metadaddy (n=metadadd@c-76-102-134-32.hsd1.ca.comcast.net) has joined #openid
  250. [14:54:47] * metadaddy (n=metadadd@c-76-102-134-32.hsd1.ca.comcast.net) Quit (Excess Flood)
  251. [14:54:54] <yonas> ok
  252. [14:55:35] <yonas> where's the IRC server in all this?
  253. [14:56:20] <yonas> so far, i see that 2-legged oauth is a good HTTP digest
  254. [14:56:46] <yonas> but the IRC server wants to know if the user owns the identity foobar@example.com
  255. [14:58:31] <yonas> i understand what these protocols do separately, but let's run through the flow of a IRC client logging into a IRC server with his openID foobar@example.com
  256. [14:59:21] <josephholsten> you understand the openid bit right? give it a shot
  257. [15:00:15] <yonas> The user types in /register foobar@example.com
  258. [15:00:48] <yonas> 2. IRC Client sends message to IRC Server
  259. [15:00:48] <yonas> "I'd like to begin an openid login, OP: example.com"
  260. [15:01:27] <yonas> 3. IRC server creates a OpenID request
  261. [15:01:27] <yonas> 4. IRC server sends request URL to IRC Client
  262. [15:01:56] <yonas> 5. We're stuck...? :)
  263. [15:02:22] <yonas> or 5. Magic happens
  264. [15:02:22] <yonas> 7. Yahoo sends back OpenID success response
  265. [15:02:23] <yonas> 8. IRC Client sends message to IRC Server
  266. [15:02:23] <yonas> "This is the response information'
  267. [15:02:23] <yonas> 9. IRC Server uses the information to confirm/verifies that the login was successful
  268. [15:02:24] <yonas> 10. IRC Server now recognizes the user as foobar
  269. [15:02:27] <yonas> foobar@example.com
  270. [15:02:46] <yonas> so what magic happens for step 5
  271. [15:02:56] <josephholsten> OK, what is step 3
  272. [15:03:16] <yonas> the irc server creates a OpenID request
  273. [15:03:52] <yonas> # After normalizing (Normalization) the User-Supplied Identifier, the Relying Party performs discovery (Discovery) on it and establishes the OP Endpoint URL that the end user uses for authentication. It should be noted that the User-Supplied Identifier may be an OP Identifier, as discussed in Section 7.3.1 (Discovered Information), which allows selection of a Claimed Identifier at the OP or for the protocol to proce
  274. [15:03:53] <yonas> ed without a Claimed Identifier if something else useful is being done via an extension (Extensions).
  275. [15:03:53] <yonas> # (optional) The Relying Party and the OP establish an association (Establishing Associations) -- a shared secret established using Diffie-Hellman Key Exchange (Rescorla, E., “Diffie-Hellman Key Agreement Method,” .) [RFC2631]. The OP uses an association to sign subsequent messages and the Relying Party to verify those messages; this removes the need for subsequent direct requests to verify the signature after ea
  276. [15:03:55] <yonas> ch authentication request/response.
  277. [15:04:54] <josephholsten> from IRC server to OP, gets a shared secret with Diffie-Hellman
  278. [15:05:13] <yonas> yup
  279. [15:05:14] <josephholsten> what's step 4
  280. [15:05:32] <yonas> The Relying Party redirects the end user's User-Agent to the OP with an OpenID Authentication request (Requesting Authentication).
  281. [15:05:52] <yonas> the RP would be the IRC server
  282. [15:06:41] <josephholsten> right. so this is where things diverge
  283. [15:07:25] <yonas> unless the IRC server runs a webserver,
  284. [15:07:45] <josephholsten> because the user-agent/irc client/consumer shouldn't need to be a browser to make the OpenID Authentication request
  285. [15:07:53] <yonas> we won't be redirecting successful logins to a return_url
  286. [15:08:02] <yonas> yup
  287. [15:08:20] <josephholsten> the IRC server doesn't need to redirect through an HTTP 302 per se
  288. [15:08:40] <josephholsten> just tells the irc client where to go
  289. [15:08:55] <yonas> i mean, there's not action like "go here after the user logins in"
  290. [15:08:55] <josephholsten> which it knows anyway, since it knows how to log in there
  291. [15:09:16] <josephholsten> there is, it's later
  292. [15:09:30] <josephholsten> that's step 8
  293. [15:09:44] <yonas> true
  294. [15:11:06] <yonas> ok
  295. [15:11:54] <josephholsten> so, the IRC client got a message back from the IRC server saying, "I talked to that guy who's _supposedly_ your open-identity provider. We agreed to a codeword. Go talk to your so-called provider and get me some proof. Or else"
  296. [15:12:14] <yonas> :)
  297. [15:12:15] <yonas> yea
  298. [15:12:37] <yonas> BREAK YO-SELF FUUU!
  299. [15:12:56] <yonas> anywho
  300. [15:13:24] <yonas> where do we go after step 4
  301. [15:13:30] <yonas> without using a browser
  302. [15:13:39] <yonas> oauth won't help us
  303. [15:13:51] * qwp0 (n=qwp0@gw.localnet.sk) Quit (Read error: 113 (No route to host))
  304. [15:13:59] <josephholsten> so, step 5: walk up to identity provider and gently ask what sort of identification they might accept. Visa, mastercard, these lovely greed identity cards with benjamin franklin on them?
  305. [15:14:04] <josephholsten> green*
  306. [15:14:24] <josephholsten> anyway, you ask, and they remind you that they speak oauth
  307. [15:14:43] <yonas> hmmmmmmmmmmmmmmmmmmmmmmmm
  308. [15:14:49] <josephholsten> last week, you two agreed to a password for just this sort of situation
  309. [15:15:29] * xpo (n=xpo@bearstech/xpo) has joined #openid
  310. [15:16:50] <yonas> is that what the openid_oauth_extension is
  311. [15:17:10] <josephholsten> you pick a number you've never ever used before for a nonce, a number larger than the last timestamp you used, and write it down next to your username and password
  312. [15:17:40] <josephholsten> then you run HMAC-SHA1, and get a signature only you could have
  313. [15:19:10] <josephholsten> you hand your identity provider the nonce, timestamp, username and signature. They check it out, and realize that despite their great fondess of you, they hadn't recognized you. But "It's really you!" they cry with a little too much excitement
  314. [15:19:19] <josephholsten> and ask what you want
  315. [15:19:57] <josephholsten> you gently explain step 6, and they give you an openid authentication response for your relying party
  316. [15:20:03] <josephholsten> and you move along
  317. [15:20:36] <josephholsten> have I mentioned I fear for the day when I have children who want me to read them bedtime stories?
  318. [15:21:24] <yonas> :)
  319. [15:21:28] <josephholsten> and no, openid-oauth hybrid is the exact opposite
  320. [15:22:05] <josephholsten> it's using openid as an authentication method in three-legged oauth to negotiate for an access token
  321. [15:22:45] <josephholsten> but so long as I don't have to edit the spec, you're welcome to have it
  322. [15:23:46] <yonas> so lets' go back to the part where we're gently reminded of speaking oauth
  323. [15:23:53] <yonas> why gently?
  324. [15:23:56] <yonas> i like it rough
  325. [15:24:07] <yonas> no no............errrrrrrrr
  326. [15:24:20] <yonas> how is that accomplished
  327. [15:25:13] <yonas> and more importantly, if the OP doesn't support oauth, are we screwed?
  328. [15:27:34] <josephholsten> as with HTTP Basic and Digest, the reminder is defined in urn:ietf:rfc:2617, your standard HTTP Authorization: header , with a scheme of OAuth, as per http://oauth.net/core/1.0/#auth_header
  329. [15:27:40] <josephholsten> and yes
  330. [15:27:54] <josephholsten> but that's really what I want to work on
  331. [15:28:24] <josephholsten> generally, figuring out what a server supports or doesn't is called discovery
  332. [15:33:01] <josephholsten> on the web we have: [HTTP headers (including Options, Accept, &c), <html><head><link rel="nifty" href="texas" /></head></html>, microformats, XRDS, RDF generally, POWDER specifically, RESTful hypertext driven document types of every sort]
  333. [15:36:42] <yonas> k
  334. [15:38:32] <josephholsten> so just to cover all your authentication bases, you'll want to check for TLS encapsulation, HTTP authentication headers (basic, digest, oauth), link headers(xrds, openid and oauth eventually), content-type headers (saml, xrds, rdf, powder), HTML head links (openid, yadis/xrds, powder), and other links inside the document which have rdfa or rel (rdf, powder, xrds). If you find an rdf, powder, or xrds document or link, keep diving, becau
  335. [15:39:47] <josephholsten> sad thing is that this list is only the reasonable half of the possible standards you might want to use
  336. [15:45:03] <yonas> interesting
  337. [15:46:40] <yonas> how many OP's already speak oauth?
  338. [15:48:01] <yonas> I need someone to test this against
  339. [15:50:45] <yonas> I'm willing to use my own server if an oauth speaking OpenID server exists
  340. [15:56:19] <yonas> I just looked at Yahoo login's HTTP headers
  341. [15:56:30] <yonas> HTTP/1.x 200 OK
  342. [15:56:30] <yonas> Date: Sat, 16 May 2009 15:56:37 GMT
  343. [15:56:30] <yonas> P3P: policyref="http://info.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE LOC GOV"
  344. [15:56:30] <yonas> Cache-Control: private
  345. [15:56:30] <yonas> Connection: close
  346. [15:56:32] <yonas> Transfer-Encoding: chunked
  347. [15:56:34] <yonas> Content-Type: text/html
  348. [15:56:36] <yonas> Content-Encoding: gzip
  349. [15:56:38] <yonas> nothing useful
  350. [16:01:13] <josephholsten> I've not heard of one. The only thing I've heard of is support for TLS client certs
  351. [16:01:50] <yonas> dang
  352. [16:02:07] <yonas> how long until it's available? who's working on it?
  353. [16:19:16] <yonas> hard to say eh
  354. [16:19:58] <yonas> maybe i'll write the first openid speaking oauth server!
  355. [16:20:00] <yonas> mew ahhahahhahah!
  356. [16:39:48] * qwp0 (n=qwp0@gw.localnet.sk) has joined #openid
  357. [17:03:45] * mosites (n=mosites@udp008530uds.hawaiiantel.net) has joined #openid
  358. [17:04:15] * mosites (n=mosites@udp008530uds.hawaiiantel.net) Quit (Client Quit)
  359. [17:32:46] <yonas> josephholsten: I posted to general@openid.net. I'll see what those guys say and come back
  360. [17:33:37] <yonas> josephholsten: thanks for your amazing amount of help :)
  361. [17:33:58] * yonas (n=yonas@CPE001a706e7734-CM00111ade9e1c.cpe.net.cable.rogers.com) Quit ("bye bye")
  362. [17:33:59] <josephholsten> yonas: I haven't done anything yet
  363. [17:47:50] * xpo (n=xpo@bearstech/xpo) Quit ()
  364. [18:47:58] * xpo (n=xpo@bearstech/xpo) has joined #openid
  365. [19:06:37] * mosites (n=mosites@udp008530uds.hawaiiantel.net) has joined #openid
  366. [19:12:26] * hacktolive (n=ubuntu@bl8-127-99.dsl.telepac.pt) has joined #openid
  367. [19:20:28] * hacktolive (n=ubuntu@bl8-127-99.dsl.telepac.pt) has left #openid
  368. [19:23:41] * mosites (n=mosites@udp008530uds.hawaiiantel.net) Quit ()
  369. [19:27:37] * qwp0` (n=qwp0@gw.localnet.sk) has joined #openid
  370. [19:33:26] * singpolyma (n=singpoly@c-76-21-5-96.hsd1.ca.comcast.net) has joined #openid
  371. [19:56:44] * qwp0 (n=qwp0@gw.localnet.sk) Quit (Read error: 110 (Connection timed out))
  372. [20:14:34] * qwp0` (n=qwp0@gw.localnet.sk) Quit (Remote closed the connection)
  373. [20:18:38] * qwp0` (n=qwp0@gw.localnet.sk) has joined #openid
  374. [20:21:38] * qwp0` (n=qwp0@gw.localnet.sk) Quit (Remote closed the connection)
  375. [21:16:34] * josephholsten (n=josephho@ip68-0-70-106.tu.ok.cox.net) Quit (Client Quit)
  376. [21:52:20] * singpolyma (n=singpoly@c-76-21-5-96.hsd1.ca.comcast.net) Quit ("Lost terminal")
  377. [21:56:26] * singpolyma (n=singpoly@c-76-21-5-96.hsd1.ca.comcast.net) has joined #openid
  378. [22:07:44] * singpolyma (n=singpoly@c-76-21-5-96.hsd1.ca.comcast.net) Quit ("Lost terminal")

These logs were automatically created by OpenIDlogbot on chat.freenode.net using a modified version of the Java IRC LogBot.