[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xdi] 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]