[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xdi] XDI article for PDJ
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
<markus.sabadello@xdi.org>**wrote: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
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<xdi-unsubscribe@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
---------------------------------------------------------------------
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]