[WG-UMA] Lexicon madness

Eve Maler eve at xmlgrrl.com
Fri Feb 19 10:47:21 EST 2010


On 19 Feb 2010, at 7:20 AM, Paul C. Bryan wrote:

> I'm also having a bit of trouble with some of the new lexicon. First
> blush from first reading:
> 
> 1. Representation
> This collides with the R in REST and is used heavily in HTTP as well
> (see RFC 2616 and search for the word "representation"). I don't think
> we can argue that both usages of the word have the same meaning. If you
> need to make this distinction in the lexicon—I'm not sure you do—off the
> top of my head, the word "statement" seems better-fitting to me.

Oh crap, didn't think of that. :-)  "Statement" doesn't seem to have any clashing definitions at http://dictionary.law.com, so it probably won't confuse anyone if we use it (and it's shorter, so that's better).

> 
> 2. Access authorization policy
> Is there a reason just "policy" is not sufficient? Also, I don't think
> you can explicitly exclude claims from policies. Policies may or may not
> require claims to result in an successful authorization. We're not
> defining policies in the protocol, so policy should remain abstract in
> our definitions anyway.

Aha, to date I had been making a clear separation between policies (AM can act unilaterally) and terms (AM ultimately needs claims from the requester), but it's true that user interfaces will probably just use "policies" or some other generic word for both.  So should I bother defining it at all?  Do we have to say anything about the relationship of the user's terms to policy-setting?

E.g., if the user clicks on "require a promise to adhere to CC-BY-SA licensing" in their policy interface, these are the user's terms for granting access, and the requesting party has to transmit an agreement.  Protocol-wise, the AM turns this into a communication about claims-required, and the requester has to cough up a claims document with a claim that encodes this promise (some kind of CC-BY-SA-agreement="yes" formulation).

> 
> 3. Primary resource user
> Why distinguish this from the authorizing user? If Alice decides to
> delegate authorization decisions to Bob, I don't think that's our
> business, and doesn't warrant adding complexity to the lexicon and/or
> protocol to support.

We probably don't need it for the real protocol, given the direction we're going.  But it may be helpful for a non-normative lexicon, to enable us to discuss custodian use cases of various kinds.

I was looking at the Littlest Pet Shop Online last night (http://lpso.com -- ponies! rainbows!), and the "real" users have to be under 14, but they have to provide the email address of a parent as part of their account provisioning.  The parent gains certain kinds of control over the account that would suggest they could also accomplish an introduction to their chosen AM if LPSO were to become UMA-enabled.



> 
> 4. Foo, Foo application, Foo service
> Do we need to call these out in our lexicon, or can Foo be sufficient
> and we can call-out application/service when required? In fact, I'd
> probably be fine defining "application" and "service" in the lexicon
> without "Foo".

Good idea.  We already got rid of the similar "foo intermediary" terms.

> 
> 5. Requesting party
> Why is it not simply "A person who directs a requester to access a
> protected resource."? Sure reads easier. Also, it's definitely *not* the
> sole party responsible for making representations. A third-party issuer
> can (and I expect will) do that too.

First comment: It's not always a person.  If you offer to sell your demographic data in a Hey, Sailor fashion to InfoUSA, InfoUSA is the requesting party.

Second comment: Damn.  This formulation was an artifact of undoing the "contract" language, and the "contract" language is why we had the "party" stuff in there in the first place.  Not sure what to do here, but I know we need to be clear about the legal layer to gain some sort of enforceability.

> 
> Perhaps my current radically-simply-the-protocol mindset is affecting my
> reading of the lexicon, but I think it can do with some simplifications,
> even if it means we have to be more explicit in some descriptions. I
> just don't want to scare-away an audience who stops reading the spec
> before getting through the terminology.

Agreed.  But how do we do that when it comes to enforceability?

(I'm not sure I can hold off doing more editing -- my trigger finger is itching!  But if I do, I'll send links to the old and new versions so others who participate in this thread can follow along accurately.)

	Eve


Eve Maler
eve at xmlgrrl.com
http://www.xmlgrrl.com/blog



More information about the WG-UMA mailing list