See also: IRC log
Date: 8 January 2009
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
AB: agenda
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0033.html
... any change requests?
[None]
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?
[None]
<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
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?
[None]
RESOLUTION: we resolve XML Sign 1.1 will be the basis for our spec
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
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?
[None]
AB: who can help?
FH: I can help but it isn't a high priority
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
AB: which WG do we want to request feedback?
MC: I18N WG
... 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
FH: XML Sec
... 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
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]