[Openid-specs-heart] UMA Profile Skeleton

Justin Richer jricher at mit.edu
Fri Apr 24 06:54:58 UTC 2015


    
All the text is new text, I didn't copy anything in this document from outside. You're mis-interpreting what I said, which I realize is easy to do when the rendered version isn't available yet. I'm not sure it even complies yet.
This profile does a few things to uma in the same way that the OAuth profile does a few things to OAuth. It does this by specifying new text that notifies uma, which is included by reference. It's a profile, that's its job. The normative document links aren't all set up yet though, so it's reference by hand-waving at the moment.
So, rest assured, no worries.
-- Justin
/ Sent from my phone /

-------- Original message --------
From: Mike Jones <Michael.Jones at microsoft.com> 
Date: 04/23/2015  10:07 PM  (GMT-05:00) 
To: Justin Richer <jricher at MIT.EDU>, openid-specs-heart at lists.openid.net 
Cc: Eve Maler <eve.maler at forgerock.com>, Debbie Bucci <Debbie.Bucci at hhs.gov>, Don Thibeau <don at oidf.org> 
Subject: RE: [Openid-specs-heart] UMA Profile Skeleton 

Hi Justin,

Wearing my board member hat, I need to ask about the IPR provenance of the text that you checked in.  What prompted me to write was your description that your checkin "does a few things to UMA", making me think that you took existing text from an IETF or Kantara UMA spec, modified it, and checked it into an OpenID repository.  The potential problem with that is that text may owned by another organization and the HEART working group may not have a clear license to use it.

One way to solve this would be to have the other organization that owns the text join the HEART working group and explicitly contribute the text to the OIDF.  There may be other ways as well, such as a clear licensing statement in the original text allowing unrestricted derivative works.

I hope that that can be resolved post haste.  If not, as a board member, I will have to ask you to remove the text owned by others from any OIDF repositories until such time as it has been unambiguously contributed to the HEART working group.

I hate to sound obstructionist, but my intent is exactly the opposite.  I'm trying to *enable* IPR-clean specs to emerge from the HEART working group, so that all will be free to use them.

				-- Mike

-----Original Message-----
From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Justin Richer
Sent: Thursday, April 23, 2015 2:38 PM
To: openid-specs-heart at lists.openid.net
Subject: [Openid-specs-heart] UMA Profile Skeleton

An updated skeleton of the UMA profile has been uploaded into the repository. This is still very thin and short, and presently example-free, but it basically does a few things to UMA to bring it inline with the OAuth and OIDC specs:

 - Inherit everything from the OAuth and OIDC profiles (this helps keep everything short)
 - All tokens (AAT, PAT, RPT) are JWTs and are introspectable, with a required set of claims pointing to specific values
 - All tokens are the bearer profile defined in UMA
 - Two claims-gathering flows are defined, both are MTI
    - Client presents an OIDC ID token directly to the RPT endpoint
    - Client sends the requesting party to an endpoint on the AS where the requesting party logs in with OIDC to provide claims directly

There are placeholders for token lifetimes, but no values yet. The OAuth token lifetimes are based on my personal deployment experience and some previous profiling work (RHEx), but I don’t have a similar feel for the UMA tokens. Should these be specific to the type of client as well?

Another question, should we have classes of protected resources? Since they’re OAuth clients as well, but they’re always a web API of some type, perhaps there’s less specificity needed here.

I’m still working with the OIDF folks to have a place to publish the rendered HTML versions of the specs, but I’m hoping to have that up in the next couple weeks timeframe.

 — Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150424/b1f828d8/attachment.html>


More information about the Openid-specs-heart mailing list