[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
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)
Les Chasen
Joseph Boyle
Markus Sabadello
Peter Davis
Phil Windley
Drummond Reed
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.
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. We then talked about next steps. Dan suggested that, for the use cases presented, we should discuss whether any additional security exchanges need to take place or else note why they're not required. We started to get to this in a discussion about whether the UMA / OAuth / XDI messages needed to signed or encrypted, something which OpenID Connect now supports by reference to the JOSE specs which Dan started to review last week. Dan noted that we would required TLS anyway, something that OpenID requires but UMA does not. Peter noted that TLS protection is broken on any flow that redirects through a browser. So in those scenarios, tokens or other data that are being passed between entities need to be signed.
Further, we didn't discuss in the UMA scenarios whether OpenID Connect authentication was required (for Bob's AS to get an ID token or UserInfo to propoerly categorize Alice). We also need to decide how in the both the XDI case and the UMA /OAuth case we know from the flow that keys used to sign messages are valid, or if not we can check their status not revoked (hopefully without getting into a full PKI situation).
To continue progress, our next steps are:
Identify the precise set of use cases that need to be diagrammed. In particular, we need to be specific how is each use case triggered. For example, in the flows above, 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).
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
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.
Great minutes Drummond, and thanks so much Peter and Markus for the excellent sequence diagrams. I found the exercise quite productive.Drummond, can you add to the minutes that, for the use cases presented, we should discuss whether any additional security exchanges need to take place or else note why they're not required? We started to get to this in a discussion about whether the UMA / OAuth / XDI messages needed to signed or encrypted, something which OpenID Connect now supports by reference to the JOSE specs which I'd started to review last week. I noted that we would required TLS anyway, something that OpenID requires but UMA does not. Peter noted that TLS protection is broken on any flow that redirects through a browser. So in those scenarios, tokens or other data that are being passed between entities need to be signed.Further, we didn't discuss in the UMA scenarios whether OpenID Connect Authentication was required (for Bob's AS to get an ID token or UserInfo to propoerly categorize Alice). We also need to decide how in the both the XDI case and the UMA /OAuth case we know from the flow that keys used to sign messages are valid, or if not we can check their status not revoked (hopefully without getting into a full PKI situation).DanOn Fri, Jul 19, 2013 at 9:31 PM, Drummond Reed <drummond.reed@xdi.org> wrote:
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]