[Openid-specs-heart] UMA Profile Skeleton

Mike Jones Michael.Jones at microsoft.com
Fri Apr 24 02:07:29 UTC 2015


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


More information about the Openid-specs-heart mailing list