[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: IMI TC Minutes, Jan 8 2009
|
1.
Call to order/roll call Attendance:
2.
Reading/Approving minutes from last meeting http://lists.oasis-open.org/archives/imi/200812/msg00000.html
Minutes
approved 3. TC Logistics (10 minutes or less) None 4.
Issues list -
Actions AI:
Chairs to request new issue list from TC admin Requested,
waiting on list to be setup None -
Issues http://wiki.oasis-open.org/imi/IssueList New
issues: 10 Version skew
between spec and schema http://lists.oasis-open.org/archives/imi/200901/msg00011.html
Agreement, assigned
to editors to correct 11 Namespace
correction In working with
OASIS staff to publish our CD discovered that we need to add our declared ns to
the document. In addition the ns string needs to be revised to reflect OASIS
guidelines: http://docs.oasis-open.org/imi/ns/identity-200810/
Agreement, assigned
to editors to correct Issues 12, 13 and
14 http://lists.oasis-open.org/archives/imi/200901/msg00005.html
12 (2
in msg) Clarifying when an ic:IssuerId value is required Discussion
on list, agreed on language, to update in new editor draft Agreement, assigned
to editors to correct 13 (3
in msg) Clarifying that self-issued cards support the PPID claim even though
not listed as an ic:SupportedClaimType element Selectors
implicitly support this claim even when not written to the transfer format Add
compatibility note on older selector behavior, deprecated behavior Agreement, assigned
to editors to correct 14 ( 1
in msg) Clarifying that the ClientPseudonym/PPID value is always sent when a
PPID is requested Assigned to editors
to propose text in revised editor’s draft based on discussion to date Note: Editors to make sure it clear that it is RP specific
information, but is cryptographically secure to not be RP identifiable Issue
1 Affirmative statements http://lists.oasis-open.org/archives/imi/200901/msg00003.html
Discussed
doc signing reqs, related to legal reqs Req for
signing alg, XAdES only know qualified sig mechanism Possibility
to capture claim in SAML token to contain value of enveloping sig over textual
statements Need
ability for RP to say for specific claim types to say what they want value of
claim to be and that they need to be signed May
need special handling of selector, e.g. user consent captured and reflected as
sig from personal card / cert over data Need
for crypto-alg flexibility (Issue 2) may go away if sig value data within token
rather than over May
require extension to protocol to signal this requirement, needs further
discussion Issue 3
Signature formats: XAdES Investigation
has shown that XAdES cannot sign over the envelope 5.
Other business Editors
to produce revised draft before next call 6.
Adjournment |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]