Note: No meeting next week.
https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not…
2018-02-16
Attending: Eve, Colin, Jim, Thomas, Tim, Sal
The International Association for Contract and Commercial Management (IACCM)
<https://www.iaccm.com/> as 40K or so members. It's old and venerable and
works on "the contract problem". For large businesses, this looks like:
coming up with a legal vs. a business deal, being unable to react to
events, having insufficiently agile contracts, etc. Marketing, purchasing,
and other business roles are engaging. They have chapter and annual
meetings: Europe, NA, and Australasia. Jim is now head of the tech
community, a new role. His goal is to network and bring together the
threads around improving transacting. Tim Cummins founded IACCM. They are
increasingly aware that businesses must play in networks and supply chains.
Does a KI/IACCM liaison make sense? Colin and Jim can talk offline about
this possibility.
What is the premise of machine readability in our model? The terms of the
license in our model could be conveyed through the form of a smart contract
or in some machine readable form.
Jim: Smart contracts aren't really contracts. Thomas: All smart-contracts
need (a) Digital Identities and (b) some way to control ledger access by
those identitiers. I would think Kantara is best possition to address the
"edges" of a blockchain system. Colin: Agree with you Thomas. Actually the
folks starting to operationalize ID on the BC are opening up to
conversations about how to assure those pieces.. after having said
initially 'we're new, we're hip, we know everything'.. a year on there is
some appreciation that the essence of many aspects of the identity
assurance puzzle don't change - only the environment that they operate in..
Jim: And (following Thomas) the blockchains may be something like the
"edges" between resource and authorization nodes.
Regulators are only nibbling at the edges of really fundamental and core
identity issues, which KI is perfectly positioned to weigh in on. And UMA2
is well positioned to answer permissioning questions.
Are all the smart contract questions too big for now? What if we just go
for the mappings that enable machine readability if you want it? If you can
end up with stable text that can live at the end of a URL, that may be
sufficient for now so that we don't go nuts trying to solve the world's
smart contract identity problems before testing the UMA business model
proposition in front of us.
Our business model report focuses on the resource owner/data subject and
requesting party/requesting party agent needs first. But what about the
IACCM "personas"? For example, slide 11 in the Legal Role Definitions deck
shows "delegation relationships" we haven't yet captured in the report: how
a service provider becomes an RSO or a CO. They would get "purple arrows"
because they're partially based on UMA technical artifacts (namely, OAuth
client credentials).
Would we want to output clause templates? Sounds like it. Jim: Think in
terms of general engagement, specific engagement, deployment. See this
example
<http://www.commonaccord.org/index.php?action=doc&file=G/TechContractsCom-IT…>he's
working with. The use case: A company is buying data processing or
consulting services. In this case it's US domestic, but we want to make
ours GDPR-enabled so that it compels a particular pipeline of enforcement
actions. With all the subcontracting, Jim guesses that GDPR will dictate a
lot of the contractual terms.
We have to pick a use case. Two candidate we've talked about include:
- Origo/Pensions Dashboard
- Health IoT
For our use case, will it require multiple natural languages? We'll have to
see.
It would an uninteresting test of UMA not to include the Federated
Authorization portion of the specs, so let's assume we're including the
"Licensing access granting permissions on RO's behalf" relationship portion.
We also have to enumerate the legal devices that would be created. There
are static and dynamic ones.
- Agreement that turns a service provider into an RSO (wasn't included
in business model report)
- Agreement that turns a service (or app) provider into a CO (wasn't
included in business model report)
- Agreement that enables a Person to acts on behalf of a Data Subject
- Agreement(s) that delegates authorization for an ASO to grant access
permissions on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Agreement(s) that delegates authorization for an RSO to manage
resources on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Does the PAT simply link to all these previous agreements in order to
establish that the RO has agreed to the "licensing of access granting
permissions on RO's behalf"? We think so
- It's possible to profile UMA to require that the basis for PAT
issuance is interactive vs. silent – this is something we could consider
building in to the agreements above, to ensure that a human RO
is given the
change to consent in a GDPR-compliant way
- There should be a way to force interactive user consent again if
there is a new version of the agreement available
- (to be continued next time - licensing of permissions and the
requesting party side of the equation)
Note that we have no meeting next week, Feb 23.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-02-15
MinutesRoll call
Quorum was reached.
Approve minutes
Approve minutes of UMA telecon 2018-02-01
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-02-01>
and UMA
telecon 2018-02-08
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-02-08>:
APPROVED.
Discussion of the new Mozilla IoT gateway project
Here is the TechCrunch article
<https://techcrunch.com/2018/02/06/mozilla-announces-an-open-framework-for-t…>.
It is using JSON-LD. Eve mused on Twitter that it could integrate with an
UMA AS to be a personal AS. Mike likes JSON-LD and noted that OTTO is using
it in preference to Fast-Fed, which is using SCIM.
IoT use cases discussed in chat:
- Thomas: Can my home panel control all my smart-appliances and manage
their respective access relationships
- Thomas: Alice-to-Alice
- Thomas: My washing machine be a "resource" to my Control Panel on the
wall
- Sal: door controllers...
- Maciej: Thomas, I think the control panel would nevertheless be the
client with the AS sitting somewhere else (potentially within the panel as
well but not necessarily)
- Maciej: I'd prefer to connect my panel to my existing AS and then use
it purely as the client, potentially requesting some new permissions as I
add new resources (i.e. new locks and what not)
- Maciej: what do you think
- Sal: actually it needs to be able to run offline, so it end up being
AS and RS and the reader is client
- Thomas: Agree. The OIC/OCF model is that there is a "Domain
Controller" (not Microsoft AD). The DC will be our AS. The Panel will be
the Client. Homeowner is the RqP
- Thomas: The thing is that some vendors are placing the DC board as
part of the wall-panel.
- Thomas: The DC board could be (should be) part of the Gateway box.
- But our UMA model fits perfectly.
- Maciej: it does, yes
- Sal: yes, most of these things have pretty archaic architectures, UMA
absolutely handles this better..
- Thomas: A bigger problem might be the multi-dwelling (non-Enterprise)
use case. Example is an Apartment building where all the apartment units
are leased.
- Thomas: The Building Owner is the legal owner, and owner of all
AC/HVAC units inside each apartment.
- Thomas: It must allow service personel access to each apartment.
- Thomas: So we potentially have a hierarchical UMA model.
- Thomas: Each apartment has its own AS. Then building owner has its
"Super-AS".
- Maciej: with the 'slave AS' being clients relying on policies in the
super AS
- Thomas: Yes. There will be local policies, and then building-wide
policies.
- Sal: Yeah, the trick is not to have one offs and hve it explode for
every control point, 1000+ policies (I have seen this) may enable the
disconnected use case but can croak the backend..
- Thomas: Agree.
Needing to push multiple tokens
Mike and Eve had been discussing offline that UMA1 allowed the pushing of
multiple claim tokens
<https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#claim-push>,
but we (deliberately) removed that capability in UMA2 at some point because
we couldn't think of a use case. Mike actually has a use case at this
point, which is to send, not multiple ID tokens per se, but "badges" such
as professional certifications (so, third-party-asserted attributes). Since
any claim token format can be defined by anyone, a "compound" claim token
format could be defined to carry multiple tokens as necessary. Each badge
would typically come from a different authority. There are various
authorities: Badgr.io, cred.ly, trailhead.salesforce.com. A badge is just a
simple JSON-encoded assertion. It's very similar to an ID token, only the
recipient part is weak. The offline version of a badge ("baked") is signed.
The hosted version is just a URL that you have to resolve (an "artifact"
pattern!). There's an MIT project called BlockCert around verifiable claims
about badges. (See our Requirements document
<https://kantarainitiative.org/confluence/display/uma/UMA+Requirements> for
proposed requirement P11 for "verifiable claims" from 2009.)
Okay, so how does such a "verifiable claim" work securely and with privacy
with an audience parameter? The issuer of a badge does specify an audience,
after a fashion, by specifying an email address. Sovrin would say: Issue a
unique DID per badge, then require that the recipient prove that they're
the owner of the DID. Mike is working on use cases where simple possession
can count for something too.
We went into a discussion of where, on a sliding scale of lightweight to
deep security and privacy, we should aim our efforts, and an observation
that specs often decide that the perfect is the enemy of the good. More
best-practices development is usually welcome and beneficial.
Charter updating
- See draft
<https://docs.google.com/document/d/1_kk8JLQZY-8eQfkWlMl0r7YJXN26dqAMTJBUMUm…>
Discussion point: Given that the UMA architecture succeeded early on in
ensuring that the "human as resource owner" use case, do the functional
requirements, which focus heavily on this use case, need to be expanded to
mention other kinds of resource owners? Eve has edited to say "a person
(human or legal person)".
Also, what about devices as/managed by resource servers? Saying "managing
data-sharing and service- *and device-access* relationships" gets us partly
there, but what about the disconnection use cases? We only did part of that
work in UMA2. We didn't get to a full set of work on locally validated
self-contained RPTs. This might be seriously interesting extension work.
Let's think on the right way to add more indications of IoT to the charter.
We didn't vote on it today but we think we're close.
Consider Tim Reiniger as WG Legal Adviser
We discussed this. There is considerable support for having him in such a
role! Is this the right name for the role? Can't think of suitable
alternatives. No time for a vote at the end of the call, but we'll pick
this up again next time.
Attendees
As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve,
Mike, Cigdem)
1. Sal
2. Andi
3. Maciej
4. Eve
5. Mike
Non-voting participants:
- George
- Thomas
- Bjorn
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not…
2018-02-09
Attending: Eve, Tim, Bjorn, Kathleen
We don't yet have Tim in a WG leadership team
<https://kantarainitiative.org/confluence/display/uma/Leadership+Team> role
with a title! And he really deserves one. [image: (smile)] How about
something like "legal adviser"? Let's bring that up at the next whole-of-WG
call.
AI: Eve: Bring up a motion on the next WG call about Tim's leadership team
role.
We made further tweaks to the 2018 charter refresh proposal
<https://docs.google.com/document/d/1_kk8JLQZY-8eQfkWlMl0r7YJXN26dqAMTJBUMUm…>
to
reflect the Legal work stream.
There's general agreement that the Consent Receipts format, so far,
accounts for general opt-in consent as known and used today, but it doesn't
account for the kind of scope-grained, asynchronous
consent/authorization/policy setting and withdrawal that UMA enables.
Things to consider in our business model: Can the ASO be a true Agent even
in the use case where the ASO is, say, your IdP and wants to be your
trusted AS, but doesn't hold any of your personal data? All your protected
resources are held in third-party RS's, so the AS hooks up with them
through PATs (OAuth) in an overt way. The challenges would be that the ASO
can still learn about:
- Which RS's Alice uses (Schwab vs. Fidelity) – could be tempted to sell
this information to advertisers
- Some notion of the nature of the protected resources, through the
metadata uploaded as part of resource registration (e.g., see the HEART
profiles, which point to FHIR Resource types) – would know what resource is
an EHR – could be tempted to sell this information
- The requesting parties associated with Alice and information about
them (graphs of relationships), to the extent of whatever claims were
collected – if the ASO isn't Facebook or Facebook-based claims aren't
collected, this presumably limits the scope of discovery of who everyone
is, but the risk is there
The theory is that these risks could be managed much better in the case of
a "personal authorization server" (which is what Adrian and Michael Chen
have built into their HIE of One implementation) because the ASO's business
model would not have to compromise for its *single* resource owner. Perhaps
it's as simple as the "pie chart" showing the ratio of
money-to-data-to-attention that the resource owner pays the service. If a
SaaS company offers an AS to millions of potential ROs, and the business
model is such that the ROs don't have to pay any money outright, then it's
really hard for the ASO to be a true Agent. In other scenarios where the AS
and the RS (or one of the RS's) are colocated, then the ASO is already
"compromised" by this:
- The ASO-that-is-also-the-RSO holds some/all of Alice's resources and
thus can see that data (so "trust mitigations of trust attacks" –
auditability of these relationships – may be needed)
Further, if the ASO also runs the client (or one of the clients) that the
RqPs use, then the ASO is already "compromised" by this:
- The ASO-that-is-also-the-CO is gaining access to resources using
tokens it issued itself (so "trust mitigations of trust attacks"
– auditability of these relationships – may be needed)
- Kathleen notes that they have been discussing signing of contracts
Tim can join the WG calls as needed for when we combine this work with
overtly technical topics. Kathleen (and Mohammad) generally can't join the
Thursday calls, so we can either schedule ad hocs as necessary or perhaps
use the Legal call time as necessary.
(A reminder: Our "Legal role definitions" deck is here
<https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…>.
The paper will be published officially by next week, but you can also find
the unofficial version, which has all the diagrams, in our mail archives
here
<https://docs.google.com/viewer?a=v&pid=forums&srcid=MDg2MjA2NjEyODIxNjA0NDI…>
.)
*AI:* Eve: Ask colleagues if their health IoT storyboard could be used as a
starting point for the POC idea.
*AI:* Eve: Reach out to Jim Hazard to alert him to the POC idea.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-02-08
MinutesRoll call
Quorum was reached.
Approve minutes
Approve minutes of UMA telecon 2018-02-01
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-02-01>:
Deferred.
Charter updating
Andi speaks in favor of putting all the design principles/requirements into
the charter by value. It's a "historical document". Justin questions
whether linking off to another document is valuable. If it doesn't add
value, then it shouldn't be done.
Eve asks whether we should vote to approve the "UMA Legal mission"
statement as a new design principle. Then we could add it to the
Requirements
<https://kantarainitiative.org/confluence/display/uma/UMA+Requirements>
document
in any case. The text in the draft charter right now: "accelerating the
ability of individuals, organizations, and legal representatives of them
both to adopt, deploy, and use UMA-enabled services in a manner consistent
with protecting privacy rights." A short phrase might be "Accelerate
privacy protection in business". Is the candidate DP sufficiently distinct
from other existing ones? Maybe not.
We could also, if we want, update the approved requirements
<https://kantarainitiative.org/confluence/display/uma/UMA+Requirements> to
use UMA 2.0 technical language.
*AI:* Eve: Revise the charter proposal
<https://docs.google.com/document/d/1_kk8JLQZY-8eQfkWlMl0r7YJXN26dqAMTJBUMUm…>
for
consideration in next week's call.
New UMA Server: Pauldron
Is there interest in having Mohammad Jafari join us for a call to show us
around Pauldron? It's listed on the Implementations
<https://kantarainitiative.org/confluence/display/uma/UMA+Implementations>
page.
Yes; Eve will reach out.
Attendees
As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve,
Mike, Cigdem)
1. Domenico
2. Sal
3. Andi
4. Maciej
5. Eve
6. Mike
Non-voting participants:
- Thomas
- Justin
- Scott F
-
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
FYI. Sorry for not having flagged this earlier.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
---------- Forwarded message ----------
From: Sonia Chiasson <sonia.chiasson(a)usenix.org>
Date: Thu, Feb 8, 2018 at 9:53 AM
Subject: 4 Days Left to Register Your SOUPS 2018 Paper Submissions!
To: "eve(a)xmlgrrl.com" <eve(a)xmlgrrl.com>
[image: SOUPS 2018, August 12–14, 2018, in Baltimore, MD, USA]
<http://s.usenix.org/acton/ct/2452/s-0268-1802/Bct/l-1bc7/l-1bc7:db/ct0_0/1?…>
Greetings,
This is a final reminder to register your paper submissions for the
Fourteenth Symposium on Usable Privacy and Security (SOUPS 2018
<http://s.usenix.org/acton/ct/2452/s-0268-1802/Bct/l-1bc7/l-1bc7:db/ct0_1/1?…>).
The deadline to do so is this *Monday, February 12*. Paper registration is
mandatory. Make sure to review the Call for Papers
<http://s.usenix.org/acton/ct/2452/s-0268-1802/Bct/l-1bc7/l-1bc7:db/ct1_0/1?…>
for submission instructions.
You still have time to submit proposals for workshops, tutorials, and
hackathons that support exploration and networking related to topics of
interest to the usable privacy and security community. The proposal
deadline is *Monday, February 26*. See the Call for Workshops, Tutorials,
and Hackathons
<http://s.usenix.org/acton/ct/2452/s-0268-1802/Bct/l-1bc7/l-1bc7:db/ct2_0/1?…>
for details and information on how to participate.
We look forward to receiving your submissions!
Sonia Chiasson, *Carleton University*
Rob Reeder, *Google*
SOUPS 2018 Technical Papers Co-Chairs
soups18chairs(a)usenix.org
The email address sonia.chiasson(a)usenix.org is for automated list
management only (e.g., email changes, unsubscribe requests).
To contact the SOUPS 2018 Chairs, please use soups18chairs(a)usenix.org. This
alias will reach Program Committee Chairs Sonia Chiasson and Rob Reeder, as
well as General Chair Mary Ellen Zurko and Vice General Chair Heather
Richter Lipford.
About this mailing list:
USENIX never shares, sells, rents, or exchanges email addresses of its
members or conference attendees.
We would like to continue sending you occasional email announcements like
this one. However, if you no longer want to receive emails from USENIX,
please click here
<http://s.usenix.org/acton/rif/2452/s-0268-1802/-/l-1bc7:db/l-1bc7/zout?sid=…>
to opt out.
If you have any questions about the mailing list, please email
office(a)usenix.org. We may also be reached via postal mail at:
USENIX Association
2560 Ninth St, Suite 215, Berkeley, CA 94710, USA
<https://maps.google.com/?q=2560+Ninth+St,+Suite+215,+Berkeley,+CA+94710,+US…>
(NOTE: We decided to cancel the Legal call tomorrow.)
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-02-01
MinutesRoll call
Quorum was reached.
Approve minutes
Approve minutes of UMA telecon 2018-01-18
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-01-18>:
APPROVED.
*Note:* Joint consent receipt ad hoc call happening in the next hour
Note! (see calendar
<https://kantarainitiative.org/confluence/display/uma/Calendar>)
Legal update
The Draft Report will be up shortly. Tim introduced Eve to an attorney who
is interested in this work.
2018 charter and roadmap discussion
- Joint consent receipt work
- Legal/business/trust (related to the above) (see relevant issues
<https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…>
)
- Extension opportunities (see relevant issues
<https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…>
)
- What else?
Mike has mentioned an extension idea around JSON Logic
<http://jsonlogic.com/>, which describes a simple way to get AND/OR logic
and has a lot of libraries. See this use of it
<https://gluu.org/docs/ce/3.1.2/admin-guide/uma/#scopes-expressions>; the
idea is that the RS could express that the user could have (or the resource
is associated with?) scope X OR scope Y (or something like that). Mohammad
Jafari has recently release a new UMA server called Pauldron
<https://medium.com/@jafarim/introducing-pauldron-an-experimental-uma-server…>
that
implements some extension ideas. Eve and James have been discussing UMA
requirements with some customers that may result in some extension
proposals. We have saved off a variety of issues
<https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…>
that
might be interesting to look at once again. Justin notes that protected
discovery may need some work.
Profiles are also interesting. Many probably want to remain third-party,
but it would be nice to point off to them. Financial use cases are
interesting. The Pensions Dashboard use case starts with a phase that's
"mostly plain OAuth" with a bit of stuff where UMA is helpful, but then
proceeds to a classic Alice-to-Bob sharing flow.
*AI:* Eve: Reach out to find what happened to the Pensions Dashboard
profile doc and see if the WG should be pointing to it.
So what's our list of anticipated activities?
- Joint work with consent receipts
- Legal/business/trust (consider changing subgroup name?)
- Extension opportunities – decide which become work items as required
- Promote adoption – could offer guidance on profiling and extension
creation by third parties in various sectors (gov, fintech, healthcare...)
- Promote interop? – known that it's challenging
Our familiar discussion about interop: Cross-matrix testing is not that
great an experience or productive. A test framework is better. UMA, like
OAuth itself, is more challenging to test than something like OIDC (it can
protect any API, and more, it has more moving parts that have to
interoperate). Assumption: Only AS conformance testing would be on the
table first, as only OP conformance testing was done for the first long
while.
Justin is involved in the OB testing effort. A lot of community members
would be interested to throw in on a broader conformance testing effort.
*AI:* Eve: Produce charter draft for review.
Updates on auxiliary material editing if any
No updates.
(after end of call) Joint consent receipt/UMA ad hoc notes
Attending: Andrew, Eve, Andi, Domenico, James, Justin, Sal, Tim, Colin
Our previous notes are here
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-11-30>
.
Andrew: A consent receipt fits in as an interoperable security audit log
entry. It has richness of detail so that it can be processed as something
that goes beyond security use cases. The goal is to fulfill the
individual's objectives. Andi: If a company gets a subject access request,
what happens next? If the audit trail includes a consent receipt, isn't it
still very valuable to them? Okay, so maybe "security" isn't the best word.
The current design of Consent Receipts focuses on traditional opt-in
consent. UMA is sort of more policy-driven.
Regarding dictating flows and formats: Interacting claims gathering is
outside the view/scope of UMA; a profile could dictate a particular thing
happening. There are several "consent receipt"-ish formats extant.
The Security Events WG formed a couple of years ago. We've identified more
than just consents as artifacts deserving of "receipts". Would a security
event token be appropriate, given this? Justin isn't sure that the SET is a
good match at this point, actually.
Eve: Muses about the scope of the UMA WG regarding "receipt workflow" sorts
of work. Should we be thinking bigger regarding things like the shoebox
endpoint (while keeping it appropriately modularized)?
The regs that are dictating that a purpose statement be included (and have
specific requirements) would seem to give problems to a RO-specified
purpose (user-submitted terms). But why can't our license-based model carry
a purpose?
What if we were to propose a POC that develops an end-to-end technical
artifact/legal device connection? Tim: Go for the gold and make it
GDPR-ready! What would such a POC entail? Does it depend on a running UMA
instance, and/or CommonAccord, and/or template clauses, and/or what
exactly? It would need to demonstrate:
- Some of the key mappings
- A realistic and evocative business use case – EU jurisdiction and
(which?) sector
- A step-by-step end-user walkthrough with "receipts" that Alice (and
Bob?) and Larry and Linda the Lawyers (for different parties – how many do
we need?) find useful
Eve has an UMA health+IoT+IRM demo that we could perhaps "port" to smart
home for this purpose. Let's figure out next steps in the Friday calls,
e.g. timeline and answering all the questions posed above.
We decided that this served as our UMA Legal call for the week, [image:
(smile)] and we'll cancel for tomorrow.
Attendees
As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve,
Mike, Cigdem)
1. Domenico
2. Sal
3. Maciej
4. Eve
5. Mike
Non-voting participants:
- James
- Justin
- Mark
-
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
