On Dec 12, 2015, at 8:35 PM, Debbie Bucci <debbucci@gmail.com> wrote:Is the second issue Mike raises the one Justin said he filed an issue - https://github.com/KantaraInitiative/wg-uma/issues/154 ?_______________________________________________On Thu, Dec 10, 2015 at 10:41 AM, Adrian Gropper <agropper@healthurl.com> wrote:UMA adds a lot of value over OAuth because it's easier to adopt to a very broad and deep ecosystem when the RS - RO interaction is separated in time from the RS - C interaction. In healthcare, this is called health information exchange and the separation allows for out-of-band RS - C discovery processes. In IoT this enables delegation where my RSs and Cs are layered like an onion around me (the layers in order: implants, wearables, mobile, router, family, cloud services). My AS is the only thing that ties these together and it needs to be as accepting of the different scopes as possible.Adrian
On Thursday, December 10, 2015, Mike Schwartz <mike@gluu.org> wrote:Mark,
I still think UMA adds a lot of value over OAuth2 alone! Also, my hope is that we can enable a migration plan to a better architecture.
- Mike
On 2015-12-10 06:57, Mark Dobrinic wrote:
Hi Mike,
Don't forget the as_uri that accompanies the ticket that the RS returns
to the UMA Client, in the protocol-step that you're trying to optimize.
Maybe the better question is that if you assume you know which scopes to
request, and the AS to make that request, why use UMA and not just plain
OAuth?
Mark
On 10/12/15 03:23, Mike Schwartz wrote:
Pedro,
It doesn't make sense to me that the RS would obtain the RPT...
Personally, I like the design of the permission ticket, because the UMA
Client does not need to know the scopes. Forcing the UMA Client to know
the scopes creates a tight bundling with the security infrastructure,
and may expose too much information to the UMA Client. I equate this to
hard coding LDAP schema in your application. It puts the infrastructure
team in a bad situation if the schema changes, because you need to re-QA
the app.
However, some people think that just because Google does something, it
must be right, or it must scale. So my interest in supporting this
feature has more to do with aligning with an existing (bad) pattern.
- Mike
On 2015-12-09 19:37, Pedro Igor Silva wrote:
----- Original Message -----
From: "Mike Schwartz" <mike@gluu.org>
To: wg-uma@kantarainitiative.org
Sent: Wednesday, December 9, 2015 6:36:32 PM
Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain
API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT
providing the scopes. And this RPT might be acceptable a certain RS for
certain resource sets.
We might have already discussed this, but wouldn't this make UMA more
compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the
AS wants to make policies based on client claims (client id, domain
specific catagory, etc). So I'm not saying eliminate the AAT. However,
if the policy for access is based on network address only, or perhaps
some other fraud detection technique that doesn't involve client
identification, I could see a case where the AAT is not needed. So maybe
the AAT could be optional?
- Mike
What about the case below ? I think it was lost because I was not able
to send messages to this list ...
"I think that when you are in NPE scenario, the permission ticket does
not make much sense. This is pretty much related with my second round
of questions.
Please correct me if I'm wrong. It seems that the permission ticket is
mostly intended to perform a transactional authorization flow, where a
RqP will ask permissions to access some one resources and the RO will
be able to receive some kind of notification and actually approve this
permission any time in the future. Or even to support multiple ASs
within the same RS, where the user can choose which AS should be used
to obtain permissions for his resources. Here I can see a lot of
value, like for cloud and IoT authz ...
However, considering NPE use cases, specially when the RO is the RS, a
1:1 relationship between RS and AS and there is no need for a
transactional authorization flow given that RS is protecting its own
resources, it might be unnecessary to use a permission ticket in this
case. But just:
1) Client tries to access protected resource on behalf of an user (no
RPT was sent)
2) RS obtain a RPT for the resource (or with additional resources and
scopes) from AS
3) RS validates the response from AS, validates the RPT, enforce
authorization and returns the RPT to the client (considering that RPT
has the right permissions)"
Any thoughts ?
-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
mike@gluu.org
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
--
-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
mike@gluu.org
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
--Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma