UMA interfaces diagram
I’ve been working on a diagram that tries to describe how an UMA AS is also an OAuth AS and RS underneath, etc. This has been percolating in my brain for possibly YEARS. Please let me know if it’s useful, and if it could be improved. I often find myself having to point out that an UMA RS "acts in the role of an OAuth client” when it uses a PAT at the UMA AS, but this finally explains the rest of the story… :-) Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
Here’s an updated version, with some tweaks/fixes, in PNG this time. Comments still welcome!
On 30 Sep 2015, at 10:27 AM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
I’ve been working on a diagram that tries to describe how an UMA AS is also an OAuth AS and RS underneath, etc. This has been percolating in my brain for possibly YEARS. Please let me know if it’s useful, and if it could be improved. I often find myself having to point out that an UMA RS "acts in the role of an OAuth client” when it uses a PAT at the UMA AS, but this finally explains the rest of the story… :-)
Eve
<uma-interfaces.pptx>
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
Eve, I find this one very helpful. It’s the picture I couldn’t quite hold in my head reading the spec. —Keith -- email & jabber: keith.hazelton@wisc.edu<mailto:keith.hazelton@wisc.edu> calendar: http://go.wisc.edu/i6zxx0 From: <wg-uma-bounces@kantarainitiative.org<mailto:wg-uma-bounces@kantarainitiative.org>> on behalf of Eve Maler Date: Thursday, October 1, 2015 at 14:01 To: "wg-uma@kantarainitiative.org<mailto:wg-uma@kantarainitiative.org> UMA" Subject: Re: [WG-UMA] UMA interfaces diagram Here’s an updated version, with some tweaks/fixes, in PNG this time. Comments still welcome! [cid:E2E34B9C-3D19-443B-9A5B-561AB5C6C4EC@mgmresorts.com] On 30 Sep 2015, at 10:27 AM, Eve Maler <eve@xmlgrrl.com<mailto:eve@xmlgrrl.com>> wrote: I’ve been working on a diagram that tries to describe how an UMA AS is also an OAuth AS and RS underneath, etc. This has been percolating in my brain for possibly YEARS. Please let me know if it’s useful, and if it could be improved. I often find myself having to point out that an UMA RS "acts in the role of an OAuth client” when it uses a PAT at the UMA AS, but this finally explains the rest of the story… :-) Eve <uma-interfaces.pptx> Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com<mailto:xmlgrrl@gmail.com> _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org<mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com<mailto:xmlgrrl@gmail.com>
Excellent! I know exactly what you mean. :-) Hmm, maybe we should include this in the UIG?
On 1 Oct 2015, at 12:41 PM, Keith Hazelton <keith.hazelton@wisc.edu <mailto:keith.hazelton@wisc.edu>> wrote:
Eve,
I find this one very helpful. It’s the picture I couldn’t quite hold in my head reading the spec. —Keith -- email & jabber: keith.hazelton@wisc.edu <mailto:keith.hazelton@wisc.edu> calendar: http://go.wisc.edu/i6zxx0 <http://go.wisc.edu/i6zxx0>
From: <wg-uma-bounces@kantarainitiative.org <mailto:wg-uma-bounces@kantarainitiative.org>> on behalf of Eve Maler Date: Thursday, October 1, 2015 at 14:01 To: "wg-uma@kantarainitiative.org <mailto:wg-uma@kantarainitiative.org> UMA" Subject: Re: [WG-UMA] UMA interfaces diagram
Here’s an updated version, with some tweaks/fixes, in PNG this time. Comments still welcome!
<uma-interfaces.png>
On 30 Sep 2015, at 10:27 AM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
I’ve been working on a diagram that tries to describe how an UMA AS is also an OAuth AS and RS underneath, etc. This has been percolating in my brain for possibly YEARS. Please let me know if it’s useful, and if it could be improved. I often find myself having to point out that an UMA RS "acts in the role of an OAuth client” when it uses a PAT at the UMA AS, but this finally explains the rest of the story… :-)
Eve
<uma-interfaces.pptx>
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
<uma-interfaces.png>_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
Hi Eve Sorry I’ve been off working and not had time to help out. I love diagrams – nice work - I hope these observations help: Diagrams represent a viewpoint, and the viewers position is best explained with some supporting narrative. You’ve used colours to separate functional components, please can you add a key. There are three phases – what does the diagram look like for each phase? Is Control required? Is Mange the right word, do you mean Protect? Make the TLAs clear by capitalising To aide readability try turning the OAuth AuthZ Server round so it can be read like the purple and green boxes. I’m happy to have a chat session and tidy the diagram if you like. Regards Robert From: wg-uma-bounces@kantarainitiative.org [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Eve Maler Sent: 02 October 2015 02:48 To: Keith Hazelton Cc: wg-uma@kantarainitiative.org UMA Subject: Re: [WG-UMA] UMA interfaces diagram Excellent! I know exactly what you mean. :-) Hmm, maybe we should include this in the UIG? On 1 Oct 2015, at 12:41 PM, Keith Hazelton <keith.hazelton@wisc.edu<mailto:keith.hazelton@wisc.edu>> wrote: Eve, I find this one very helpful. It’s the picture I couldn’t quite hold in my head reading the spec. —Keith -- email & jabber: keith.hazelton@wisc.edu<mailto:keith.hazelton@wisc.edu> calendar: http://go.wisc.edu/i6zxx0 From: <wg-uma-bounces@kantarainitiative.org<mailto:wg-uma-bounces@kantarainitiative.org>> on behalf of Eve Maler Date: Thursday, October 1, 2015 at 14:01 To: "wg-uma@kantarainitiative.org<mailto:wg-uma@kantarainitiative.org> UMA" Subject: Re: [WG-UMA] UMA interfaces diagram Here’s an updated version, with some tweaks/fixes, in PNG this time. Comments still welcome! <uma-interfaces.png> On 30 Sep 2015, at 10:27 AM, Eve Maler <eve@xmlgrrl.com<mailto:eve@xmlgrrl.com>> wrote: I’ve been working on a diagram that tries to describe how an UMA AS is also an OAuth AS and RS underneath, etc. This has been percolating in my brain for possibly YEARS. Please let me know if it’s useful, and if it could be improved. I often find myself having to point out that an UMA RS "acts in the role of an OAuth client” when it uses a PAT at the UMA AS, but this finally explains the rest of the story… :-) Eve <uma-interfaces.pptx> Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com<mailto:xmlgrrl@gmail.com> _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org<mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com<mailto:xmlgrrl@gmail.com> <uma-interfaces.png>_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org<mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com<mailto:xmlgrrl@gmail.com> ________________________________ Capgemini is a trading name used by the Capgemini Group of companies which includes Capgemini UK plc, a company registered in England and Wales (number 943935) whose registered office is at No. 1, Forge End, Woking, Surrey, GU21 6DB. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Thanks for the great input, as always, Robert! A key is an excellent idea. This is what was intended: Purple = UMA protection API Green = UMA authorization API Blue = Internal OAuth security layer for UMA-standardized APIs The three phases are taken from Figure 1 of the UMA spec. The verbs beyond the phase verbs are taken from the (non-normative) UMA marvelous spiral, where the verbs were nonetheless chosen with some care; Figure 1 actually also uses them. The only new verb phrase is “elevate trust”, a detail that I thought was important to include because it’s part of the functioning of the RPT endpoint. The RO manages resources by virtue of “being online” at an RS ("having an account" is a crude way of putting it but usually accurate). We could say the RO “manages” access by virtue of similarly “being online” at an AS, but it’s not really that helpful to repeat the same verb, so we chose “control” to mean “control access”. We reserved “protect” for what the AS does, and that’s why we call the AS-RS API the “protection API”. What TLAs haven’t been capitalized? The protection API labeling is at the bottom to keep it out of the way of the client-server flow, which goes down. The authorization API labeling is at the top to keep it out of the way of the client-server flow, which goes up. I made the OAuth security labeling go sideways to keep it generally out of the way, because those endpoints are “meta”: they're available to both APIs presented by the UMA AS. Is there a better way to show that than to copy the positioning of one of the other two? (Happy to take the group off this thread if it gets too extensive!…) Eve
On 12 Oct 2015, at 9:13 AM, Lapes, Robert <robert.lapes@capgemini.com> wrote:
Hi Eve Sorry I’ve been off working and not had time to help out. I love diagrams – nice work - I hope these observations help:
Diagrams represent a viewpoint, and the viewers position is best explained with some supporting narrative. You’ve used colours to separate functional components, please can you add a key. There are three phases – what does the diagram look like for each phase? Is Control required? Is Mange the right word, do you mean Protect? Make the TLAs clear by capitalising To aide readability try turning the OAuth AuthZ Server round so it can be read like the purple and green boxes.
I’m happy to have a chat session and tidy the diagram if you like.
Regards Robert
From: wg-uma-bounces@kantarainitiative.org [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Eve Maler Sent: 02 October 2015 02:48 To: Keith Hazelton Cc: wg-uma@kantarainitiative.org UMA Subject: Re: [WG-UMA] UMA interfaces diagram
Excellent! I know exactly what you mean. :-) Hmm, maybe we should include this in the UIG?
On 1 Oct 2015, at 12:41 PM, Keith Hazelton <keith.hazelton@wisc.edu <mailto:keith.hazelton@wisc.edu>> wrote:
Eve,
I find this one very helpful. It’s the picture I couldn’t quite hold in my head reading the spec. —Keith -- email & jabber: keith.hazelton@wisc.edu <mailto:keith.hazelton@wisc.edu> calendar: http://go.wisc.edu/i6zxx0 <http://go.wisc.edu/i6zxx0>
From: <wg-uma-bounces@kantarainitiative.org <mailto:wg-uma-bounces@kantarainitiative.org>> on behalf of Eve Maler Date: Thursday, October 1, 2015 at 14:01 To: "wg-uma@kantarainitiative.org <mailto:wg-uma@kantarainitiative.org> UMA" Subject: Re: [WG-UMA] UMA interfaces diagram
Here’s an updated version, with some tweaks/fixes, in PNG this time. Comments still welcome!
<uma-interfaces.png>
On 30 Sep 2015, at 10:27 AM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
I’ve been working on a diagram that tries to describe how an UMA AS is also an OAuth AS and RS underneath, etc. This has been percolating in my brain for possibly YEARS. Please let me know if it’s useful, and if it could be improved. I often find myself having to point out that an UMA RS "acts in the role of an OAuth client” when it uses a PAT at the UMA AS, but this finally explains the rest of the story… :-)
Eve
<uma-interfaces.pptx>
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
<uma-interfaces.png>_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
Capgemini is a trading name used by the Capgemini Group of companies which includes Capgemini UK plc, a company registered in England and Wales (number 943935) whose registered office is at No. 1, Forge End, Woking, Surrey, GU21 6DB. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
I took another stab at the diagram and posted it on the UMA home page… Changes: Gray and italic for out-of-band Rationalization of the order of text for API and endpoint labels Rationalization of size of boxes throughout Correction/adjustment of arrow verbs Addition of abbreviations for all UMA terms Addition of expansion for RPT abbreviation Legend in lower left http://kantarainitiative.org/confluence/display/uma/Home
On 12 Oct 2015, at 10:01 AM, Eve Maler <eve@xmlgrrl.com> wrote:
Thanks for the great input, as always, Robert! A key is an excellent idea. This is what was intended:
Purple = UMA protection API Green = UMA authorization API Blue = Internal OAuth security layer for UMA-standardized APIs
The three phases are taken from Figure 1 of the UMA spec.
The verbs beyond the phase verbs are taken from the (non-normative) UMA marvelous spiral, where the verbs were nonetheless chosen with some care; Figure 1 actually also uses them. The only new verb phrase is “elevate trust”, a detail that I thought was important to include because it’s part of the functioning of the RPT endpoint.
The RO manages resources by virtue of “being online” at an RS ("having an account" is a crude way of putting it but usually accurate). We could say the RO “manages” access by virtue of similarly “being online” at an AS, but it’s not really that helpful to repeat the same verb, so we chose “control” to mean “control access”. We reserved “protect” for what the AS does, and that’s why we call the AS-RS API the “protection API”.
What TLAs haven’t been capitalized?
The protection API labeling is at the bottom to keep it out of the way of the client-server flow, which goes down. The authorization API labeling is at the top to keep it out of the way of the client-server flow, which goes up. I made the OAuth security labeling go sideways to keep it generally out of the way, because those endpoints are “meta”: they're available to both APIs presented by the UMA AS. Is there a better way to show that than to copy the positioning of one of the other two?
(Happy to take the group off this thread if it gets too extensive!…)
Eve
On 12 Oct 2015, at 9:13 AM, Lapes, Robert <robert.lapes@capgemini.com <mailto:robert.lapes@capgemini.com>> wrote:
Hi Eve Sorry I’ve been off working and not had time to help out. I love diagrams – nice work - I hope these observations help:
Diagrams represent a viewpoint, and the viewers position is best explained with some supporting narrative. You’ve used colours to separate functional components, please can you add a key. There are three phases – what does the diagram look like for each phase? Is Control required? Is Mange the right word, do you mean Protect? Make the TLAs clear by capitalising To aide readability try turning the OAuth AuthZ Server round so it can be read like the purple and green boxes.
I’m happy to have a chat session and tidy the diagram if you like.
Regards Robert
From: wg-uma-bounces@kantarainitiative.org <mailto:wg-uma-bounces@kantarainitiative.org> [mailto:wg-uma-bounces@kantarainitiative.org <mailto:wg-uma-bounces@kantarainitiative.org>] On Behalf Of Eve Maler Sent: 02 October 2015 02:48 To: Keith Hazelton Cc: wg-uma@kantarainitiative.org <mailto:wg-uma@kantarainitiative.org> UMA Subject: Re: [WG-UMA] UMA interfaces diagram
Excellent! I know exactly what you mean. :-) Hmm, maybe we should include this in the UIG?
On 1 Oct 2015, at 12:41 PM, Keith Hazelton <keith.hazelton@wisc.edu <mailto:keith.hazelton@wisc.edu>> wrote:
Eve,
I find this one very helpful. It’s the picture I couldn’t quite hold in my head reading the spec. —Keith -- email & jabber: keith.hazelton@wisc.edu <mailto:keith.hazelton@wisc.edu> calendar: http://go.wisc.edu/i6zxx0 <http://go.wisc.edu/i6zxx0>
From: <wg-uma-bounces@kantarainitiative.org <mailto:wg-uma-bounces@kantarainitiative.org>> on behalf of Eve Maler Date: Thursday, October 1, 2015 at 14:01 To: "wg-uma@kantarainitiative.org <mailto:wg-uma@kantarainitiative.org> UMA" Subject: Re: [WG-UMA] UMA interfaces diagram
Here’s an updated version, with some tweaks/fixes, in PNG this time. Comments still welcome!
<uma-interfaces.png>
On 30 Sep 2015, at 10:27 AM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
I’ve been working on a diagram that tries to describe how an UMA AS is also an OAuth AS and RS underneath, etc. This has been percolating in my brain for possibly YEARS. Please let me know if it’s useful, and if it could be improved. I often find myself having to point out that an UMA RS "acts in the role of an OAuth client” when it uses a PAT at the UMA AS, but this finally explains the rest of the story… :-)
Eve
<uma-interfaces.pptx>
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
<uma-interfaces.png>_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
Capgemini is a trading name used by the Capgemini Group of companies which includes Capgemini UK plc, a company registered in England and Wales (number 943935) whose registered office is at No. 1, Forge End, Woking, Surrey, GU21 6DB. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
participants (3)
-
Eve Maler -
Keith Hazelton -
Lapes, Robert