IMI TC Minutes, April 30th 2009

1. Call to order/roll call

Mario Ivkovic A-SIT, Zentrum fur sichere Informationstec...

Jeffrey Broberg CA*

Drummond Reed Cordance*

Michael McIntosh IBM

Bruce Rich IBM

John Bradley Individual

Scott Cantor Internet2

Marc Goodner Microsoft Corporation

Michael Jones Microsoft Corporation

Dale Olds Novell*

Lost voting status

None

Gained voting status

None

2. Reading/Approving minutes from last meeting

http://lists.oasis-open.org/archives/imi/200904/msg00033.html

Minutes approved

3. TC Logistics (10 minutes or less)

Reminder; chat room: http://webconf.soaphub.org/conf/room/imi

Call next week is on

Prepare to move 1.0 spec to CD/CS and on for OASIS standardization

4. Issues list

- Actions

Old issue list needs to be cleaned up, e.g. all issues marked closed or pointing to new issue list as appropriate.

Old issue list:

http://wiki.oasis-open.org/imi/IssueList

Not done

AI Chairs to add link to home page to new issue list.

Not done

AI Chairs to ask Mary for resolved state in JIRA

- Issues

http://tools.oasis-open.org/issues/browse/IMI

Done (we weren’t using it right, after an issue is filed it has to be opened then the other interim states show up)

IMI 1.0 issues

PR spec needs a 2119 review

http://tools.oasis-open.org/issues/browse/IMI-2

Final changes in ed-09.

http://lists.oasis-open.org/archives/imi/200904/msg00039.html

http://lists.oasis-open.org/archives/imi/200904/msg00040.html

Resolved

Validate XML in spec is well formed

http://tools.oasis-open.org/issues/browse/IMI-6

Applied in ed-09.

http://lists.oasis-open.org/archives/imi/200904/msg00039.html

http://lists.oasis-open.org/archives/imi/200904/msg00040.html

Resolved

Sec 8.1 Definition of canonical string representation of the IP address of the server is ambiguous

http://tools.oasis-open.org/issues/browse/IMI-16

Applied in ed-09.

http://lists.oasis-open.org/archives/imi/200904/msg00039.html

http://lists.oasis-open.org/archives/imi/200904/msg00040.html

Resolved

The values to use from a certificate to construct the Client Pseudonym need clarification

http://tools.oasis-open.org/issues/browse/IMI-17

Applied in ed-09.

http://lists.oasis-open.org/archives/imi/200904/msg00039.html

http://lists.oasis-open.org/archives/imi/200904/msg00040.html

Resolved

Unicode encodings used not fully specified

http://tools.oasis-open.org/issues/browse/IMI-18

Applied in ed-09.

http://lists.oasis-open.org/archives/imi/200904/msg00039.html

http://lists.oasis-open.org/archives/imi/200904/msg00040.html

Resolved

Agreed editorial and non-substantive change.

New public comment:

http://lists.oasis-open.org/archives/imi-comment/200904/msg00001.html

Break into multiple issues:

Missing "claim type" in text

http://tools.oasis-open.org/issues/browse/IMI-19

line 687 says:

This optional element provides a friendly name for this individual.

It should read:

This optional element provides a friendly name for this individual claim type.

Assigned to editors

Agreed editorial and non-substantive change.

Unclear text on end of STS chain

http://tools.oasis-open.org/issues/browse/IMI-20

Section 2.3 is much less clear then the rest of the document.

lines 383-385 say:

When following a chain of STSs, when an STS with an ic:RequireFederatedIdentityProvisioning declaration is

encountered as per Section 3.2.1, this informs the Identity Selector that the STS is an IP/STS, rather than a

member of the RP/STS chain.

It is not clear what this means or what its significance is. If the intent is that the IP/STS marks the end of the chain, why not say so?

Change: this informs the Identity Selector that the STS is an IP/STS

To: this informs the Identity Selector that the STS is an IP/STS and therefore ending the STS chain

Assigned to editors

Agreed editorial and non-substantive change.

PPID in lines 390-392 should spell out what it stands for

http://tools.oasis-open.org/issues/browse/IMI-21

The mention of PPID in lines 390-392 should spell out what it stands for (private personal identifier) and include a forward reference to section 3.3.4 where it is defined. Perhaps this section could be moved to later in the document after PPID has been described.

Assigned to editors

Agreed editorial and non-substantive change.

Usage of term certificate is unclear

http://tools.oasis-open.org/issues/browse/IMI-22

The text makes repeated references to "certificate". Is certificate distinct from "token"? What qualifies as a certificate? PK certificate? X.509 certificate? PKIX profiled certificate? Does a Kerberos token qualify? How about a SAML token with a PK? What role does this certificate play? does it represent the identity of one of the parties? if so, which one? is it an encryption key for one of the parties?

lines 397-399 say:

Each RP/STS endpoint MUST provide a certificate. This certificate MAY be communicated either via Transport (such

as HTTPS) or Message (such as WS-Security) Security. If Message Security is employed, transports not providing

security (such as HTTP) may be used.

Is the sender required to provide PoP of the private key? How exactly is the certificate to be sent? In the SOAP body? In the Security header?

Agreed to add definition of certificate to terminology section, note that it means X.509 unless otherwise qualified. Include description that certificate usage is dictated by underlying protocols, e.g. HTTPS or WSS except where noted.

Editors to double check if there are any instances of certificate that are not X.509.

Assigned to editors

Agreed editorial and non-substantive change.

IMI 1.1 issues

IMI version next prerequisites

http://tools.oasis-open.org/issues/browse/IMI-3

Add the new optional elements ic:InformationCard/ic09:CardType and ic:InformationCard/ic09:IssuerName

http://tools.oasis-open.org/issues/browse/IMI-13

X509 credential enhancements

http://tools.oasis-open.org/issues/browse/IMI-14

Information Card Provisioning

http://tools.oasis-open.org/issues/browse/IMI-15