Minutes: XDI TC Telecon Friday 2013-07-19

XDI TC Minutes

Following are the minutes of the unofficial telecon of the XDI TC at:

Date:  Friday, 19 July 2013 USA
Time:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)

ATTENDING

Les Chasen 

Joseph Boyle

Markus Sabadello

Peter Davis

Phil Windley 

Drummond Reed 

AGENDA
NEWS & UPDATES
CLOUD IDENTITY SUMMIT REPORT

Drummond, Les, Peter, Dan, and Markus shared that they had an excellent set of sessions with Eve Maler and other UMA experts to discuss XDI security flows.

PRESENTATIONS/DISCUSSIONS
XDI SECURITY PATTERNS

We continued our review of mechanisms for XDI message authentication and authorization and how they align with OAuth and PKI.

   https://wiki.oasis-open.org/xdi/XdiMessagePatterns

   https://lists.oasis-open.org/archives/xdi/201305/msg00048.html 

First, Peter reviewed the following diagram (including source text from WebSequenceDiagrams.com) of what the security flows would look like in the basic “Alice & Bob” scenario following the UMA (User Managed Access) drafft specification.



title Basic Alice to Bob use case for initial introduction to Bob's CSP

participant "Alice"

participant "AliceAS"

participant "AliceCSP"

participant "Bob"

participant "BobCSP"

participant "BobAS"

participant "Discovery"

Bob->BobCSP: register service

BobCSP->BobAS: resource registration

BobAS->BobCSP: OK

BobCSP->Bob: OK

Bob->BobAS: Allow Alice to resource

note right of BobAS: May be a generic policy\n(RBAC, etc...)

end note

BobAS->Bob: OK

Alice->Discovery: Where is Bob's CSP

Discovery->Alice: Bob's CS Location

Alice->+AliceCSP: Link contract request to Bob

AliceCSP->+BobCSP: Link contract request to Bob

BobCSP->AliceCSP: RPT Required

AliceCSP->Alice: RPT Required (authentication)

Alice->AliceCSP: authenticate

note right of BobAS

Allow explicit and implicit AS\nregistrations, so AAT message may not\nbe required

end note

AliceCSP->BobAS: AAT request

BobAS->AliceCSP: AAT Response

AliceCSP->BobAS: RPT request (with AAT)

note right of BobAS

this is where the actual\ncontract is generated

end note

BobAS->AliceCSP: RPT

AliceCSP->BobCSP: Resource request with RPT

BobCSP->BobAS: token validation

BobAS->BobCSP: response

BobCSP-->-AliceCSP: Resource

AliceCSP-->-Alice: Resource



*******

We noted in the discussion that the number of messages and tokens needed in UMA may be significantly consolidated by assuming XDI endpoints that serve in both the AS (Authorization Server) and RS (Resource Server, which is Peter’s diagram is CSP) roles.

Peter had to leave the call at 10AM PT. Continuing that discussion, Markus created another WebSequenceDiagram that showed a similar scenario using only XDI servers.

# Use this at http://www.websequencediagrams.com/

title Alice to Bob Flow in XDI

participant Alice

participant Bob

participant "Alice's XDI Server"

participant "Bob's XDI Server"

participant "XDI Discovery Service"

Bob->"Bob's XDI Server": Set up link contract

"Bob's XDI Server"->Bob: OK

alt Link contract address sent via E-Mail

  Bob->Alice: E-Mail with link contract address

else Link contract address dynamically discovered

  Alice->"Alice's XDI Server": Discover XDI link contract address

  "Alice's XDI Server"->"Bob's XDI Server": Discover XDI link contract address

  "Bob's XDI Server"->"Alice's XDI Server": XDI link contract address

  "Alice's XDI Server"->Alice: XDI link contract address

end

Alice->"Alice's XDI Server": Resource Request using XDI link contract address

"Alice's XDI Server"->"XDI Discovery Service": Discover Bob's XDI Server

"XDI Discovery Service"->"Alice's XDI Server": Discovery Result

"Alice's XDI Server"->"Bob's XDI Server": Request Resource

note right of "Bob's XDI Server"

Validate signature on Alice's

XDI message and verify

XDI link contract

end note

"Bob's XDI Server"->"Alice's XDI Server": Resource

"Alice's XDI Server"->Alice: Resource

********

In this scenario, peer-to-peer PKI is used by Bob’s XDI Server to validate Alice’s signature on the incoming resource request.

Everyone agreed this was a very useful exercise. To continue progress, our next steps are:

Identify the precise set of use cases that need to be diagrammed. In particular, how is each use case triggered, i.e., how does Alice discover the XDI resource that she will request from Bob? 

We also need to identify the precise client configuration for each use case, i.e., the security considerations for plain browser, unhosted app, and native app may all vary.

Across this matrix, prepare the diagrams the reflect the use of different authentication/authorization protocols (e.g., OAuth, OpenID Connect, UMA, PEERKI).

DECISION POINT QUEUE REVIEW

The decision queue stack is shown on the following three auto-generated Category pages:

   https://wiki.oasis-open.org/xdi/CategoryLastCall

   https://wiki.oasis-open.org/xdi/CategoryCurrent

   https://wiki.oasis-open.org/xdi/CategoryHighPriority

See also this list of proposals that need to be developed:

   https://wiki.oasis-open.org/xdi/XdiPendingIssues

NEXT CALL

Drummond will be on vacation next week, so he will not be able to attend the call, but unless Markus posts otherwise, assume there will still be a call at the regular time.