Widgets Voice Conference

08 Jan 2009


See also: IRC log


Art, Frederick, Mark, Claudio, Jere, Marcos, Doug, Mike, Josh



Date: 8 January 2009

<scribe> ScribeNick: ArtB

<scribe> Scribe: Art

Agenda review and tweak

AB: agenda http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0033.html
... any change requests?



AB: I don't have any widget-specific annoucments

FH: XML Sec WG is having a f2f meeting next week
... we will look at sig properties
... if anyone wants to attend, please let me know
... Also, if we have any comments to discuss, I can make that happen
... I may be able to rearrange things if needed

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0011.html

AB: please notify FH if you want to take advantage of it

MC: I may try to join

AB: any other annoucements?


R44. Support for Multiple Message Digest Algorithms

<fjh> +

AB: FH thinks the requirement is unclear

<arve> ArtB: as indicated, I'll be regretting

FH: need to clarify the model
... this will effect validation

MP: there may be a misunderstanding in what we are trying to achieve
... expect the sig to always be in the package

<fjh> concerned how core validation can be meaningful if signature not with references, especially if using relative uris

MP: [Mark describes some use cases that motiviated his comments]

<fjh> this sounds like an implemention optimization, not sure it belongs in spec

MP: I don't want to add complexity

FH: sounds like some pre-caching
... I think we just want to say core validation is done via XML Sig spec

MP: don't want the spec to preclude my use case
... agree we don't want to specify a separate delivery mechanism
... want to make sure the two major steps can be done in either order

AB: let's take the tech discussion to the public list

MP: I will respond to the list with more details of the use case

R45. Support for Multiple Signature Algorithms

AB: just need some clarification to SHA1 and SHA256

FH: yes, we need some clarification here
... a separate issue is XML Sig 1.1

AB: what is the status and roadmap for 1.1?

FH: we are very close to FPWD for 1.1
... will be a topic for next week's f2f meeting
... I don't expect any major issues
... I think we can align the two specs
... I think best case in about 3-4 months to start the Candidate phase
... But we need to discuss this next week

AB: so you expect 1.1 REC in 2009?

FH: yes; definitely

AB: any concerns about 1.1?

MP: are there any other major diffs for 1.1 (besides algorithms)?

<fjh> http://www.w3.org/2008/xmlsec/Drafts/roadmap/roadmap.html

FH: besides algorithms, SHA-256 migration is in scope
... we have some minor errata
... all major changes will be deferred to v2.0

AB: propose we resolve XML Sign 1.1 will be the basis for our spec
... any objections to that proposal?

MP: is it possible for this to hold up our spec?

AB: based on what FH said, I think this won't be an issue

DS: cannot go to REC if a normative reference is not a REC
... need a month for PR, month for CR, month for LC
... Given this, probably will take 4-5 months to get XML Sig to REC, perhaps a bit longer

FH: the two specs could progress together

AB: given where we are today, e.g. no tests, not in LC yet, I don't think we will be blocked by XML Sig 1.1
... Mark do you still have some concerns?

MP: I don't have any concerns about using 1.1

AB: any objections to using XML Sig 1.1?


RESOLUTION: we resolve XML Sign 1.1 will be the basis for our spec

R46 and R49

AB: the email on these shows there is agreement by Mark on FH's changes
... is that true?

FH: yes

MP: yes

AB: please implement the proposed changes

New Req proposal (5): add role of signer

AB: MP raised some questions about the use cases
... it wasn't clear to me how it would satisfied

FH: the role could be used to clarify the distributor
... could use a signature property
... I don't think the author element is relevant here

MP: if the roles are different it implies different processing

<fjh> MP: different purposes for signing , signer vouching for trust, or update signature

<fjh> MP: role of signature, not role of signer

MP: think something like this is needed but is related to the 2nd requirement proposed

<fjh> MP: usage might be better name

FH: role and usage have been dealt with elsewhere
... usage is different than policy

<fjh> define property in sig properties, values in widgets signature

<fjh> MPupdate signature indicates update of package

[Some discussions about the update mechanisms: http://dev.w3.org/2006/waf/widgets-updates/ ]

<fjh> requirment 5 should be usage instead of role

AB: is there consensus to add req 5?

MC: no, I need to consider this more

FH: I tihink we need it

MC: I want some time to think about this

AB: how much time do you need Marcos?

MC: one week

MP: I will send an email by Monday

AB: what about req 6?

<fjh> suggest profile property with uri for signature spec

MC: I'm OK with that proposal

FH: req #8 provides a motivation about the Expires property

MP: agree Expires property makes sense

<fjh> issue of granularity of time stamps?

MP: a concern I had is the text implies a short expiration period
... but I agree with the overall intent

FH: I think we need to continue discussion on req #8
... could use something from Schema

<fjh> suggest we use xsd:dateTime but need clarification of processing rules around comparisons

<timeless> hello?

AB: any last comments about FH's original email?


Section 5. definitions

AB: who can help?

FH: I can help but it isn't a high priority

Section 9 and X509

FH: do we really need to define something here?

AB: agree we should reference existing work if possible

<fjh> MP: concern about interoperability related to optional features

MP: concerened about addressing some interop issues we've had in the mobile industry

<fjh> MP: both for OCSP and CRLs

MP: we could ref some existing specs
... not sure they meet all of our reqs
... Agree there is an open question on how much X509 processing we need to specify.

AB: Mark, you will provide input on OCSP and CRLs

<fjh> http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0038.html

<fjh> http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0039.html

AB: and contributors for 6.1 and 8?

FH: I sent a proposal for 6.1 to the list earlier today
... I made a proposal for section 8 too

<timeless> ack

JS: there is a protocol for helping sort out a chain if something is missing
... Gecko has some new suport for this

P&C Last Call WD

AB: which WG do we want to request feedback?

... WAI P&F
... MWBP

<timeless> i think this is probably a related url, http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/4221005/4224052/04224150.pdf?arnumber=4224150

... the P&C should just point at the Widgets DigSig spec

MP: I think the P&C spec needs to address how to address handling more than one sig

<fjh> should point to Widgets DigSIg spec since it handles properties etc


AB: next call is Jan 15
... FH regrets already sent
... quick poll on Paris f2f attendance
... any definites?

MP: yes

AB: yes

CV: most likely

MC: I don't know

<JereK> doubtful as of now

AB: meeting adjourned

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/01/08 16:15:52 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/: propose we resolve/: we resolve/
Succeeded: s/MP: role and/FH: role and/
Succeeded: s/profile/profile property/
Found ScribeNick: ArtB
Found Scribe: Art
Default Present: +358.503.85aaaa, +44.771.751.aabb, Art_Barstow, Mark, Claudio, fjh, Marcos, Shepazu, Mike, billyjackass, Josh_Soref
Present: Art Frederick Mark Claudio Jere Marcos Doug Mike Josh
Regrets: Arve
Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0033.html
Found Date: 08 Jan 2009
Guessing minutes URL: http://www.w3.org/2009/01/08-wam-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]