OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xdi] XDI article for PDJ


Markus,
Link contract evaluation happens after token validation. If you don't have a token, the only thing you can access is $public. 

- Mike





-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
office: +1 646-810-8761
mike@gluu.org

On Sat, 7 Jul 2012, Markus Sabadello wrote:


Thanks, this is really helpful.

Maybe the ENTIRE authentication logic should be expressed in Javascript,
don't know?
This would be pretty much the opposite of Bill's idea to introduce a
hierarchy of $ words.

E.g. if you do it all in Javascript, you could have something like this in
a policy literal..

if (msg.hasAttribute("$password")) {
 if (isValidPassword(msg.getAttribute("$password")) return true;
} else if (msg.hasAttribute("$token")) {
 token = parseToken(msg.getAttribute("$token"));
 if (! isValidToken(token)) return false;
 if (token.getIssuer() == "myallowedissuer")) return true;
}
return false;

Just experimenting here..

Markus

On Sat, Jul 7, 2012 at 3:20 AM, Michael Schwartz <mike@gluu.org> wrote:



Markus,

I have put up a proposal for use of JavaScript syntax:
  https://wiki.oasis-open.org/**xdi/LCJSFunctions<https://wiki.oasis-open.org/xdi/LCJSFunctions>

You can also see examples of each of these in oxTestTool
  http://seed.gluu.org/**oxTestTool <http://seed.gluu.org/oxTestTool>
if you look at all the methods prefixed with "JS evaluation"

Actually, we are not using javascript, we are just following the JS syntax
for parsing equations which is highly optimized.

- Mike




On Sat, 7 Jul 2012, Markus Sabadello wrote:

 BTW I would still be interested in an example of what kind of JavaScript

is
going into the XDI policy nodes. What does this look like in OpenXDI?

Markus

On Sat, Jul 7, 2012 at 1:42 AM, Drummond Reed <drummond.reed@xdi.org>
wrote:

 I agree that the whole thing could be considered a policy, and so can the

individual policy statements (that's what we've been calling them,
"policy
statements"). Isn't that what XACML calls them?

=Drummond


On Fri, Jul 6, 2012 at 4:22 PM, Michael Schwartz <mike@gluu.org> wrote:



In SSO jargon, I think "policy" binds all three: #1 resources, #2
operations, #3 conditions.

For example, a CA SiteMinder "policy" (SiteMinder is typical SSO
platform) specifies the rules for the URL (#1), HTTP operations (#2),
group
membership (or attribute) requirements (#3), time of day (#3), and
required
authentication level (#3).

So I think it would be confusing to use the word "policy" just to
describe the conditions under which the operations should be allowed on
the
specified resources.

Actually, I think the closest analogy to "policy" in XDI jargon is "link
contract."


- Mike



On Fri, 6 Jul 2012, Drummond Reed wrote:

 I agree with what Mike is saying here about the third branch not being


restricted to just "direct assignment". But I'd use the word "policy"
since
that's the industry standard term, i.e., a link contract is a uniquely
addressable XDI subgraph that describes what operation can be made on
what
resources under what policies.

=Drummond

On Fri, Jul 6, 2012 at 2:35 PM, Michael Schwartz <mike@gluu.org>
wrote:


 Just a note on the link contracts... I think the three things are:


1) What resource
2) What operation(s)
3) Under what conditions

For #3, Drummond implies that you can specify what person (or XRI),
but
this is not scalable. For example, if I want to authorize teachers at
my
school, its not scalable to maintain relational links to each teacher.
Although we did create a shortcut $is$do if you can make a direct link
to
the person... I still think specifying the person is a special case
shortcut for specifying a type of condition. This is why we have
proposed
the $if subtree of the link contract.

- Mike



On Fri, 6 Jul 2012, Drummond Reed wrote:

 Markus, as we discussed on the call today, congrats on an excellent

 article. I read through the whole thing and have just a few minor

suggestions:

  - In the XRI section, you say, "For example, if the XRI =alice is
used

  within XDI data, then an XDI processor can immediately tell that it
refers
  to a person (because the = symbol is used)." To be semantically
precise,
  what an XDI processor can tell from the = global context symbol is
that
it
  this branch of the XDI graph is *controlled* by an individual
person. In

  other words, the =namespace is specified to be for identifiers
controlled
  by individuals, but which may represent any resource that the
individual
  assigns the resource too. So, for example, =alice in the XDI graph
could be
  a cat (i.e., the XDI "is a" statement could be =alice/$is+/+cat).
So,
  although the vast majority of =names and =numbers will identify
resources
  that are people, you can't make that assumption just on the basis
of
an
  =name or =number alone.
  - Since your example graph includes multiplicity syntax for
$!(+tel),

  you might add a line explaining that +tel is a phone number, and $!
is a
  way of expressing that this is a single canonical instance of a
literal
  phone number and not a collection of phone numbers (which would be
$*(+tel)
  ).
  - In the XDI Messaging section, you say, "XDI messages can be sent
over

  different protocol bindings, such as HTTP, WebSockets, or SMTP." I
used
to
  say the same thing, but practically speaking, I'm not sure anyone
will
ever
  do a XDI SMTP binding. So you might want to make the third example
XMPP,
  since that's a protocol that's on the TC's list for a binding.
  - In your XDI Link Contracts section, you way, "In its simplest
form, a

  link contract consists of two components: One or more sender XRIs
  identifying the parties who are given permissions by the link
contract
  (the “assignees”); and one or more XDI operations and XDI
addresses,
  specifying what operations are allowed on what parts of a graph." I
  summarize a link contract as always having three components,
because
  without the link contract node itself, the link contract would not
have
a
  subject. So I would suggest: "In its simplest form, a link contract
  consists of three components: the link contract XRI that uniquely
  identifies it in the graph, one or more sender XRIs identifying the
parties
  who are given permissions by the link contract (the “assignees”);
and
one
  or more XDI operations and XDI addresses, specifying what
operations
  are allowed on what parts of a graph."
  - Given the discussion on this morning's telecon, I think the
following

  might give the wrong impression: "Some work is being done to pursue
the
  vision of a tight relationship between OpenID Connect and XDI,
which
means
  that in a global, distributed ecosystem, OpenID Connect would
provide
  identity federation, and XDI would provide data federation." I
would
  suggest softening this slightly to, "Some work is being done to
obtain
the
  maximum synergy between OpenID Connect and XDI. This would enable
building
  a global distributed ecosystem in which OpenID Connect could
provide
the
  identity federation and XDI could provide the data federation."
  - Lastly, in your side box text, you say, "Like its predecessor, it
also

  assumes triples as its foundation, but also includes a strong
notions of
  contextuality." I think you meant "a strong notion" (singular) or
"strong
  notions" (plural). Or, another suggestion would be to characterize
it
this
  way: "Like its predecessor, it also assumes triples as its
foundation,
but
  more precisely defines the definitions and relations between
contexts,
and
  also clearly establishes the special roles of root nodes and
literal
(leaf)
  nodes."

Hope this helps - again, congrats on what is a great article.

Will this article be available/publicly reference-able on the web?

Thanks,

=Drummond

On Tue, Jul 3, 2012 at 3:12 PM, Markus Sabadello
<markus.sabadello@xdi.org>******wrote:



 Find attached the current draft of the XDI article for the next
issue
of

 the Personal Data Journal.


If you have any suggestions, please send in the next few days.
Also feel free to annotate the docx file and send back to me.
Perhaps we could have a quick (5 min) talk about it on the Friday
XDI
TC
call.

Markus



------------------------------******--------------------------**
--**--**
---------
To unsubscribe, e-mail: xdi-unsubscribe@lists.oasis-******open.org<
http://open.org>
<xdi-unsubscribe@**lists.**oasis-open.org<http://lists.oasis-open.org>
<xdi-**unsubscribe@lists.oasis-open.**org<xdi-unsubscribe@lists.oasis-open.org>








For additional commands, e-mail: xdi-help@lists.oasis-open.org





 ------------------------------****----------------------------**

--**
---------
To unsubscribe, e-mail: xdi-unsubscribe@lists.oasis-****open.org<http://open.org>
<xdi-unsubscribe@**lists.oasis-open.org<xdi-unsubscribe@lists.oasis-open.org>



For additional commands, e-mail: xdi-help@lists.oasis-open.org






------------------------------**------------------------------**
---------
To unsubscribe, e-mail: xdi-unsubscribe@lists.oasis-**open.org<xdi-unsubscribe@lists.oasis-open.org>
For additional commands, e-mail: xdi-help@lists.oasis-open.org









---------------------------------------------------------------------
To unsubscribe, e-mail: xdi-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xdi-help@lists.oasis-open.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]