Las Vegas Sept 16 2009

Agenda

1. Assurance Survey
2. Oauth and Delegated access
3. Whitelisting and Meta data

Roll Call

Paul Madsen NTT (Chair), Ari Kermaier Oracle, Bob Morgan Internet2, Tatsuki Sakushima NRI, Hiroki Itoh NTT, Mike Beach Boeing, Scott Cantor Internet2, Ingo Friese Deutsche Telekom, Nat Sakimura NRI, Eve Maler Paypal, Lucy Lynch ISOC, Colin Wallis NZ Gov, Joni Brennan (staff).

Discussion

Discussion on Oauth definitions of what constitutes 3-legged:

3 legged Oauth – client service and 2 other services (but no IdP). If actors include an IdP is that still 3 legged? What is Oauth to SAML? What is Oauth to IC?

Discussion on Authz:

DR situations require ‘caching’ of data. This is different from and not duplicating data in the strictest sense.

Discussion on Assurance Survey interview confirmations:

Issue is to source both interviewing organizations, and contacts within those, and interviewers.

Bob Morgan confirms he will interview Neustar (Peter Davis)

Volunteer needed to interview Internet2 (Scott and Bob)

Volunteer required to interview David Martin (Boeing?)

Lucy to find contact for interviewing at Access Grid

Bob/Scott to find contact contact at NIH (Mike Hallam?)

Colin suggests Jack Leipold at the US SSA

Bob to consider possible interviewees out of the attendee list at the ‘TAO of identity’ event

Ari to approach ‘his client’.

Discussion on Assurance Survey questionnaire construction:

How will the scope of the data change as a result of an additional request (e.g. to share data)? )Lucy to help word this correctly).

What do you do when the data changes?

How did the ‘source’ of the data obtain the data from the original?

Discussion ensued around the value of NIST 800-63 LoAs because attributes for the levels are not defined. Scott: Consider a use case where no attributes are returned. Colin Yes, No responses possibly fall into this category? Discussion around the constraints on the values of the data for example when moderated/changed by the user. Can a federated Trust model limit ‘bad acts’, to ring-fence confidence.

Whitelisting:

US eGov ICAM scheme for OID is really only whitelisting URLs, vs IC where the card issuers and their keys are whitelisted. There is interest, if not agreement that SAML is a reasonable vehicle to drive whitelisting (e.g STS SAML Token Profiles). WS Fed uses SAML metadata. WS Trust must have some equivalent? Therefore SAML metadata is a good possible candidate. Possible risk of no harmonization between SAML on one side and XRD/IOD on the other. Maybe the notion of maintaining a list of XRDs and mapping these to a whitelist (say, maintained by the US Gov?).

Scott: The structure of a whitelist exists in SAML.

Ari: The US fed gov is comfortable with PKI.

Bob: OID works off an auto-numbering system at the last step.

Scott: GSA will take it to the vendors.

General question: ‘How do we make metadata more effective, if hosting large batches is not a long term solution?’ We must track this as a potential work item.

Discussion on potential 2009/10 work items:

1. Metadata (as above)
2. Paul: OID PAPE being used further than intended, e.g. PII
3. Eve: suggestion of PAPE.next
4. Bob: PAPE for authentication policy extension.
5. OID/PAPE to SAML Gaps in proxying assume a message flow (that isn’t there?) PAPE has no equivalent to SAML proxy protocol interaction – there are rules of a sort. PAPE allows expression of LOA but not to specify it (compared to SAML LOA profile (soon to be in OASIS SSTC CD). If SAML has restrained proxy rules then OID must respect this. This to be produced and published as (A) a Kantara report (working title is ‘ A Proxying Guide’) and later, possibly a Recommendation (to line up with the equivalent to SAML LOA profile in the SSTC).

Any Other Business:

1. Meeting call times: Time slot agreed as OK, but possible the day to be moved to help Ari. Will move to BoT s ‘High def’ conferencing system to improve quality if/when able to but in the meantime continue with the take up of Intenet2’s offering.