/irc-logs / w3c / #webapps / 2009-05-04 / end

Options:

  1. # Session Start: Mon May 04 00:00:01 2009
  2. # Session Ident: #webapps
  3. # [00:37] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  4. # [01:33] * Joins: Lachy (Lachlan@85.196.122.246)
  5. # [01:39] * Joins: chaals (chaals@89.130.83.193)
  6. # [01:52] * Quits: gsnedders (gsnedders@86.136.52.180) (Client exited)
  7. # [01:55] * Quits: heycam (cam@203.217.72.53) (Quit: bye)
  8. # [02:41] * Joins: heycam (cam@130.194.73.110)
  9. # [04:47] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  10. # [05:21] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  11. # [08:21] * Quits: heycam (cam@130.194.73.110) (Quit: bye)
  12. # [08:27] * Joins: heycam (cam@130.194.221.98)
  13. # [09:40] * Joins: arve (arve@213.236.208.22)
  14. # [10:08] * Quits: heycam (cam@130.194.221.98) (Quit: bye)
  15. # [10:19] * Quits: chaals (chaals@89.130.83.193) (Quit: chaals)
  16. # [10:32] * Joins: tlr (tlr@128.30.52.30)
  17. # [10:56] * Joins: Marcos (Marcos@213.236.208.22)
  18. # [11:34] * Joins: gsnedders (gsnedders@86.136.52.180)
  19. # [11:38] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  20. # [11:51] * Joins: Lachy (Lachlan@213.236.208.22)
  21. # [11:51] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: Leaving)
  22. # [11:53] * Joins: Lachy (Lachlan@213.236.208.22)
  23. # [11:59] * Joins: anne (annevk@83.86.138.148)
  24. # [12:43] * Joins: ArtB (d0309a43@128.30.52.43)
  25. # [13:25] * Joins: gavin__ (gavin@63.245.208.169)
  26. # [13:25] * Quits: gavin__ (gavin@63.245.208.169) (Quit: leaving)
  27. # [14:14] <ArtB> Marcos, are OMTP BONDI's specs such as their "Editor Drafts" publicly readable?
  28. # [14:21] <Marcos> ArtB: I don't think so
  29. # [14:21] <Marcos> It would be nice to get some transparency to their process
  30. # [14:28] <ArtB> Marcoso. OK. The APIs Marcin proposed like Tasks API and Logging API - are they included in the BONDI 1.0 Release Candidate?
  31. # [14:36] <Marcos> Artb, I don't think so
  32. # [14:37] <Marcos> Those are not really "device API"
  33. # [14:42] <Marcos> Artb, should I bother editing the i18n document to reflect the WG's decisions and so to outline the complete solution?
  34. # [14:58] <ArtB> Marcos, re L10N doc - I think your #1 priority should be to implement the decisions in the spec, ASAP
  35. # [14:59] * Joins: aroben (aroben@71.58.77.15)
  36. # [15:00] <Marcos> Yes, but I don't want to screw it up. I'm going to do this: 1. remove all rejected proposals from the i18n doc. 2. integrate feedback, corrections to agreed on proposals 3.
  37. # [15:00] <Marcos> 3. send new doc to i18n
  38. # [15:00] * Joins: heycam (cam@203.217.72.53)
  39. # [15:12] <ArtB> Couldn't you just do that in the context of a new version of the ED (rather than continue to update a separate doc)?
  40. # [15:22] <Marcos> Artb, yes, I'm going to fold all the proposals into the P&C WD.
  41. # [15:23] <Marcos> I wrote the proposals in "spec-ise" so they could be easily folded in.
  42. # [15:23] * Quits: arve (arve@213.236.208.22) (Quit: Ex-Chat)
  43. # [15:24] <ArtB> When you say "all of the proposals", Marcos, you mean just those that were agreed, right?
  44. # [15:24] <Marcos> right
  45. # [15:24] <ArtB> :)
  46. # [15:25] <ArtB> tlr, Marcos, did you look at hendry's email re Identifier prop (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0457.html)? What would break if that property was removed from the spec?
  47. # [15:29] * Quits: Lachy (Lachlan@213.236.208.22) (Ping timeout)
  48. # [15:29] * Quits: Marcos (Marcos@213.236.208.22) (Ping timeout)
  49. # [15:29] <tlr> just sent an answer
  50. # [15:29] <tlr> baiscally, nothing breaks in the user agent, but it's a really good idea to be able to reference things that have any importance in a standardized way. Signatures are important. Keep it.
  51. # [15:30] * Joins: Marcos (Marcos@213.236.208.22)
  52. # [15:31] * Joins: Lachy (Lachlan@213.236.208.22)
  53. # [15:31] <Marcos> I think if distributors want to manage their certs, they should do so by making use of the Identifier. UAs should not be forced to support it
  54. # [15:31] <tlr> right
  55. # [15:31] <tlr> UAs will largely ignore it.
  56. # [15:31] <tlr> Does the spec say anything else right now?
  57. # [15:32] * Joins: darobin (darobin@85.169.117.248)
  58. # [15:32] * Marcos checks
  59. # [15:33] <ArtB> [[
  60. # [15:33] <ArtB> The signer uses the dsp:Identifier signature property to uniquely identify the signature to enable signature management. It MUST be unique for a given signer. Signing parties are expected to ensure that the dsp:Identifier signature property value is unique for the widget packages that they sign.
  61. # [15:33] <ArtB> ]]
  62. # [15:33] <Marcos> [[A unique identifier string for the signature MUST be placed in the dsp:Identifier signature property by the signer. This MUST be a unique signing string for all widget signatures created by the signer. Signing parties are expected to ensure that the dsp:Identifier signature property value is unique for the widgets that they sign.]]
  63. # [15:33] <ArtB> how could the uniqueness requirement ever be guaranteed?
  64. # [15:34] <Marcos> it can't
  65. # [15:34] <ArtB> so something's broken
  66. # [15:34] <ArtB> perhaps this entire section should be Non-Normative
  67. # [15:35] <ArtB> i.e. no more than a recommendation?
  68. # [15:35] <Marcos> I agree
  69. # [15:35] <ArtB> Good catch Hendry!
  70. # [15:38] <Marcos> Artb, another offending line is:
  71. # [15:38] <Marcos> [[Each widget signature MUST contain a dsp:Identifier signature properties element compliant with XML Signature Properties [XMLDSIG-Properties] and this specification.
  72. # [15:38] <Marcos> ]]
  73. # [15:38] <Marcos> Artb, can you please make sure that Frederick sees the above
  74. # [15:39] <Marcos> (otherwise, I can just paste all this into an email and ship it to public webapps)
  75. # [15:40] <ArtB> I'll do
  76. # [15:40] <tlr> Re uniqueness, there are several ways for a signer to guarantee it.
  77. # [15:41] <tlr> (a) large random number -- once it's more likely for planet earth to destroyed by Vogons than for a collission to occur, you're safe
  78. # [15:41] <tlr> (b) local serial number + DNS-based authority
  79. # [15:42] <tlr> there is no way for the UA to verify that, though
  80. # [15:42] <tlr> so, I don't think there's anything offending in here.
  81. # [15:42] <tlr> the notion of a "unique identifier" surely isn't objectionable all by its own.
  82. # [15:43] <tlr> => please keep normative and please don't remove
  83. # [15:43] <Marcos> tlr, I'm "offended" that the UA does not do anything with this
  84. # [15:43] <ArtB> tlr - understood but I think it would be good to qualify the "target" of the requirement is not the UA but the Signer
  85. # [15:43] <tlr> artb, no problem with having the target clear
  86. # [15:43] <tlr> i.e., "signers MUST put the dsp:Identifier element in there"
  87. # [15:43] <ArtB> bingo
  88. # [15:44] <Marcos> so, if the signer wants to use dsp:Indentifier, it should be left to the discretion of the signer. I don't see why it's a MUST that the id be included
  89. # [15:44] <Marcos> ?
  90. # [15:45] * Marcos does not say it's a bad thing, just that it don't do nothing at the moment.
  91. # [15:45] <tlr> there are some use cases -- e.g. signature revocation -- that will only work if a signature is *always* in the certificate.
  92. # [15:45] <tlr> Therefore, MUST.
  93. # [15:46] <Marcos> so, it's to target specific signatures?
  94. # [15:46] <Marcos> Do we need to specify how to do signature revocation?
  95. # [15:47] <tlr> we might need to at some point
  96. # [15:49] <ArtB> Marcos, my recollection is we said no to revocation for v1
  97. # [15:51] * tlr sighs. "The purpose of a signature is to revoke it." or expire it. Or something.
  98. # [15:56] <ArtB> tlr, what are you quoting i.e. "The purpose of a signature is to revoke it"?
  99. # [15:56] <tlr> random themes, not any particular book
  100. # [15:57] <tlr> The point is simply that, without revocation or expiration, you have an attack surface that's unlimited in time once a signature key gets compromised
  101. # [15:57] <tlr> and that's fairly bad
  102. # [15:58] <tlr> unfortunately, revocation regularly fails, and it would be a mircale if we were to get a *working* revocation model built here
  103. # [16:00] <ArtB> ah, so we'd need to boil the ocean to get it right
  104. # [16:01] <tlr> very likely
  105. # [16:01] <Marcos> tlr, you say the purpose of a signature is to revoke it, but then we add in this dsp:Identifier thing and we don't define how to make use of it to revoke the signature
  106. # [16:01] <tlr> the identifier is in the catebory of "give others a hook to fix the problem"
  107. # [16:02] <tlr> s/catebory/category/
  108. # [16:02] * Marcos starts to worry
  109. # [16:03] * tlr thinks Marcos shouldn't.
  110. # [16:03] <tlr> To be clear, expiration for SSL doesn't work over the Internet because too many people break it.
  111. # [16:03] <tlr> gah
  112. # [16:03] <tlr> revocation
  113. # [16:03] <tlr> expiration actually kind of works, but too many user agents give people a chance to click by
  114. # [16:03] <tlr> there is no particular reason why revocation here needs to work better (or worse) than it does for SSL.
  115. # [16:04] <tlr> However, I'm positively sure that the amount of time we're spending here on arguing over the identifier is way above the amount of time it'll cost anybody to implement it.
  116. # [16:04] * Marcos has a meeting
  117. # [16:04] <Marcos> bbl
  118. # [16:24] * Quits: gsnedders (gsnedders@86.136.52.180) (Client exited)
  119. # [16:25] * Joins: gsnedders (gsnedders@86.136.52.180)
  120. # [16:37] * Quits: Marcos (Marcos@213.236.208.22) (Quit: Marcos)
  121. # [16:43] * Joins: Marcos (Marcos@213.236.208.247)
  122. # [16:56] * Joins: smaug (chatzilla@82.181.140.15)
  123. # [17:04] * Joins: wellington (chatzilla@200.136.228.238)
  124. # [17:32] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  125. # [17:55] * Joins: Lachy (Lachlan@85.196.122.246)
  126. # [17:58] * Joins: wellington_ (chatzilla@200.136.228.238)
  127. # [17:58] * Quits: wellington (chatzilla@200.136.228.238) (Connection reset by peer)
  128. # [17:58] * wellington_ is now known as wellington
  129. # [18:18] * Joins: aroben_ (aroben@71.58.77.15)
  130. # [18:20] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
  131. # [18:20] * aroben_ is now known as aroben
  132. # [18:33] * Quits: Marcos (Marcos@213.236.208.247) (Quit: Marcos)
  133. # [18:43] * Joins: Marcos (Marcos@213.236.208.247)
  134. # [18:46] * Quits: Marcos (Marcos@213.236.208.247) (Quit: Marcos)
  135. # [19:00] <gsnedders> Hmm, looking at DOM again I again note the lack of any method that gets the root element from a document.
  136. # [19:06] * Quits: wellington (chatzilla@200.136.228.238) (Quit: ChatZilla 0.9.84 [Firefox 3.0.9/2009040821])
  137. # [19:13] <gsnedders> Oh, wait, documentElement
  138. # [19:13] <gsnedders> Ergh. Terminology fail.
  139. # [19:15] * Joins: taf2 (taf2@38.99.201.242)
  140. # [20:03] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC)
  141. # [20:31] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  142. # [21:48] * Quits: darobin (darobin@85.169.117.248) (Quit: darobin)
  143. # [21:58] * Joins: Lachy (Lachlan@85.196.122.246)
  144. # [22:24] * Joins: arve (arve@84.202.133.45)
  145. # [22:27] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  146. # [22:32] * Joins: Lachy (Lachlan@85.196.122.246)
  147. # [23:00] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  148. # [23:03] * Joins: Lachy (Lachlan@85.196.122.246)
  149. # [23:06] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
  150. # [23:54] * Joins: Lachy (Lachlan@85.196.122.246)
  151. # Session Close: Tue May 05 00:00:00 2009

The end :)