Drafts of Core and RSR specs for your immediate review

Eve Maler

1 Sep 2015 1 Sep '15

11:24 a.m.

I have attached HTML versions of the specs for you review. (I’m not posting them on the site, so that nobody gets the idea they’re finished/vetted.) Many thanks to Maciej for working on a fresh Kantara-specific XSLT transformation! His work isn’t complete, so there are a few formatting/front page things yet to do; don’t worry about those. Everybody please review these formatted specs carefully for ALL the issues you care about, and report any new issues in GitHub https://github.com/KantaraInitiative/wg-uma/issues Or feel free to send notes to the list or to me privately if you like, and I can collate them. We will discuss everything this Thursday. I think we should probably take the time to continue our review through to Sep 10 if we feel at all rushed, or want to see complete new renditions. This is because, once we exit the 45-day Public Review period, we can no longer make technical changes without going back to square 1. We should be quite sure we’re happy with these drafts when they go into review. (Luckily, I no longer have a conflict with our Sep 10 meeting.) Here are some items that we already know need editing, discussion, or review: Don’t forget that there is new wording for permission ticket lifecycle management as discussed last week, which needs your review. See Core Sec 3.2.2. Our new wording in response to #161, Protocol assumes one resource owner per URL https://github.com/KantaraInitiative/wg-uma/issues/161, says “When a client attempts access to a presumptively protected resource without an RPT,...”. This appears one place in RSR, where I changed “an RPT” to “an access token” and added an [UMA] cross-reference. But in the Core spec, should it say “an access token” generically? Maciej and I discussed some questions he had around the RSR security considerations, in RSR Sec 4. What does a “valid web page” (a phrase that came from OAuth’s version) mean? I also recently added a new issue #185, RSR user_access_policy_uri: security considerations https://github.com/KantaraInitiative/wg-uma/issues/185, that may have us tweak that section a little further if we think it has merit. I actually implemented issue #179, Use OIDC specification style of providing a subsection for every type of response https://github.com/KantaraInitiative/wg-uma/issues/179 and restructured Core so that every request and response has its own subsection — couldn't resist. :-) Of course, this meant major structural changes! Mostly I rearranged existing text, but I did end up having to rewrite section introductions and invent new introductions. And because Section 3 has a flow to it, I redid how the “flow chart” feel of the entire section works. Now the organization is a bit flatter (there is one bug I’d like to fix, which is that Core Sec 3.3-3.5 should actually be subsections in a single Sec 3.3), and each main subsection contains a consistent “how you got here” intro (and no outro). E.g.: “If the client's request at the protected resource has no RPT, or an invalid RPT or insufficient authorization data associated with the RPT as determined through RPT status checking (see Section 3.6), then assuming the resource server chooses to respond to the client,…” Thanks in advance, all, for your review and attention. Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

Attachments:

attachment.html (text/html — 4.4 KB)
draft-oauth-resource-reg-v1_0_1-2015-09-01.html (text/html — 50.3 KB)
attachment.html (text/html — 237 bytes)
draft-uma-core-v1_0_1-2015-09-01.html (text/html — 136.2 KB)
attachment.html (text/html — 527 bytes)

Show replies by date

Maciej Machulak

1 Sep 1 Sep

11:27 a.m.

Eve, Thanks for all the work towards this draft!!! Maciej On Tue, 1 Sep 2015 16:25 Eve Maler wrote:

...

I have attached HTML versions of the specs for you review. (I’m not posting them on the site, so that nobody gets the idea they’re finished/vetted.) Many thanks to Maciej for working on a fresh Kantara-specific XSLT transformation! His work isn’t complete, so there are a few formatting/front page things yet to do; don’t worry about those.

Everybody please review these formatted specs carefully for ALL the issues you care about, and report any new issues in GitHub https://github.com/KantaraInitiative/wg-uma/issues Or feel free to send notes to the list or to me privately if you like, and I can collate them. We will discuss everything this Thursday.

I think we should probably take the time to continue our review through to Sep 10 if we feel at all rushed, or want to see complete new renditions. This is because, once we exit the 45-day Public Review period, we can no longer make technical changes without going back to square 1. We should be quite sure we’re happy with these drafts when they go into review. (Luckily, I no longer have a conflict with our Sep 10 meeting.)

Here are some items that we already know need editing, discussion, or review:

- Don’t forget that there is new wording for permission ticket lifecycle management as discussed last week, which needs your review. See Core Sec 3.2.2.

- Our new wording in response to #161, Protocol assumes one resource owner per URL https://github.com/KantaraInitiative/wg-uma/issues/161, says *“When a client attempts access to a presumptively protected resource without an RPT,...”*. This appears one place in RSR, where I changed *“an RPT”* to *“an access token”* and added an [UMA] cross-reference. But in the Core spec, should it say *“an access token”* generically?

- Maciej and I discussed some questions he had around the RSR security considerations, in RSR Sec 4. What does a “valid web page” (a phrase that came from OAuth’s version) mean? I also recently added a new issue #185, RSR user_access_policy_uri: security considerations https://github.com/KantaraInitiative/wg-uma/issues/185, that may have us tweak that section a little further if we think it has merit.

- I actually implemented issue #179, Use OIDC specification style of providing a subsection for every type of response https://github.com/KantaraInitiative/wg-uma/issues/179 and restructured Core so that every request and response has its own subsection — couldn't resist. :-) Of course, this meant major structural changes! Mostly I rearranged existing text, but I did end up having to rewrite section introductions and invent new introductions. And because Section 3 has a flow to it, I redid how the “flow chart” feel of the entire section works. Now the organization is a bit flatter (there is one bug I’d like to fix, which is that Core Sec 3.3-3.5 should actually be subsections in a single Sec 3.3), and each main subsection contains a consistent “how you got here” intro (and no outro). E.g.: *“If the client's request at the protected resource has no RPT, or an invalid RPT or insufficient authorization data associated with the RPT as determined through RPT status checking (see Section 3.6), then assuming the resource server chooses to respond to the client,…”*

Thanks in advance, all, for your review and attention.

Eve

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler

12:34 p.m.

Labor of love. :-) By the way, a couple of more editing/discussion/review items for this thread: Our two IETF I-Ds from the Recommendation versions of the specs (Core https://tools.ietf.org/html/draft-hardjono-oauth-umacore-13, RSR https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06 expire on Oct 6. We haven’t yet concluded our newly reopened discussion about the IETF Independent Submission/Informational RFC route, but I suspect it’s a good idea to keep updating the I-Ds for now, since, why not…? There’s a minor structural edit I’d like to make to Core Sec 3.6 and 3.6.1, to consolidate more of the token introspection info from the introduction into the subsection. Eve

...

On 1 Sep 2015, at 8:27 AM, Maciej Machulak wrote:

Eve,

Thanks for all the work towards this draft!!!

Maciej

On Tue, 1 Sep 2015 16:25 Eve Maler mailto:eve@xmlgrrl.com> wrote: I have attached HTML versions of the specs for you review. (I’m not posting them on the site, so that nobody gets the idea they’re finished/vetted.) Many thanks to Maciej for working on a fresh Kantara-specific XSLT transformation! His work isn’t complete, so there are a few formatting/front page things yet to do; don’t worry about those.

Everybody please review these formatted specs carefully for ALL the issues you care about, and report any new issues in GitHub https://github.com/KantaraInitiative/wg-uma/issues Or feel free to send notes to the list or to me privately if you like, and I can collate them. We will discuss everything this Thursday.

I think we should probably take the time to continue our review through to Sep 10 if we feel at all rushed, or want to see complete new renditions. This is because, once we exit the 45-day Public Review period, we can no longer make technical changes without going back to square 1. We should be quite sure we’re happy with these drafts when they go into review. (Luckily, I no longer have a conflict with our Sep 10 meeting.)

Here are some items that we already know need editing, discussion, or review:

Don’t forget that there is new wording for permission ticket lifecycle management as discussed last week, which needs your review. See Core Sec 3.2.2.

Our new wording in response to #161, Protocol assumes one resource owner per URL https://github.com/KantaraInitiative/wg-uma/issues/161, says “When a client attempts access to a presumptively protected resource without an RPT,...”. This appears one place in RSR, where I changed “an RPT” to “an access token” and added an [UMA] cross-reference. But in the Core spec, should it say “an access token” generically?

Maciej and I discussed some questions he had around the RSR security considerations, in RSR Sec 4. What does a “valid web page” (a phrase that came from OAuth’s version) mean? I also recently added a new issue #185, RSR user_access_policy_uri: security considerations https://github.com/KantaraInitiative/wg-uma/issues/185, that may have us tweak that section a little further if we think it has merit.

I actually implemented issue #179, Use OIDC specification style of providing a subsection for every type of response https://github.com/KantaraInitiative/wg-uma/issues/179 and restructured Core so that every request and response has its own subsection — couldn't resist. :-) Of course, this meant major structural changes! Mostly I rearranged existing text, but I did end up having to rewrite section introductions and invent new introductions. And because Section 3 has a flow to it, I redid how the “flow chart” feel of the entire section works. Now the organization is a bit flatter (there is one bug I’d like to fix, which is that Core Sec 3.3-3.5 should actually be subsections in a single Sec 3.3), and each main subsection contains a consistent “how you got here” intro (and no outro). E.g.: “If the client's request at the protected resource has no RPT, or an invalid RPT or insufficient authorization data associated with the RPT as determined through RPT status checking (see Section 3.6), then assuming the resource server chooses to respond to the client,…”

Thanks in advance, all, for your review and attention.

Eve

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com mailto:xmlgrrl@gmail.com

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

Eve Maler

9:47 p.m.

Maybe one more while I’m at it: Inspired by Farazath’s recent question; the discussion and resolution of #163/#164/#168 concluding that the RS has quite a lot of HTTP status discretion; and this wording in Core Sec 3.5... “assuming the resource server chooses to respond to the client, it MUST give access to the desired resource” , I’m thinking we should reassess old issue #15: Must the host [RS] give access if the requester [client] has suitable permission? https://github.com/KantaraInitiative/wg-uma/issues/15. At the time, we resolved it with softer wording https://github.com/KantaraInitiative/wg-uma/commit/57aee439865aafffe33e77da4... than we have now — “When a requester presents a valid access token, the host SHOULD provide the requester with access to the desired resource. Note that that access to resources at a host remains at the discretion of the host, even in cases where the requester has presented a valid access token." — but we apparently never published the softer wording as an I-D, and undid the decision by rev 03 https://tools.ietf.org/html/draft-hardjono-oauth-umacore-03. I remember that we discussed just keeping MUST because there’s nothing UMA can do about the RS’s actions, but it may make sense to be clear to RS developers and deployers that UMA is “discretionary access control”, and an RS always has the right to refuse service (so to speak), same as an authentication RP. Eve

...

On 1 Sep 2015, at 9:34 AM, Eve Maler wrote:

Labor of love. :-) By the way, a couple of more editing/discussion/review items for this thread:

Our two IETF I-Ds from the Recommendation versions of the specs (Core https://tools.ietf.org/html/draft-hardjono-oauth-umacore-13, RSR https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06 expire on Oct 6. We haven’t yet concluded our newly reopened discussion about the IETF Independent Submission/Informational RFC route, but I suspect it’s a good idea to keep updating the I-Ds for now, since, why not…?

There’s a minor structural edit I’d like to make to Core Sec 3.6 and 3.6.1, to consolidate more of the token introspection info from the introduction into the subsection.

Eve

...
On 1 Sep 2015, at 8:27 AM, Maciej Machulak mailto:maciej.machulak@gmail.com> wrote:

Eve,

Thanks for all the work towards this draft!!!

Maciej

On Tue, 1 Sep 2015 16:25 Eve Maler mailto:eve@xmlgrrl.com> wrote: I have attached HTML versions of the specs for you review. (I’m not posting them on the site, so that nobody gets the idea they’re finished/vetted.) Many thanks to Maciej for working on a fresh Kantara-specific XSLT transformation! His work isn’t complete, so there are a few formatting/front page things yet to do; don’t worry about those.

Everybody please review these formatted specs carefully for ALL the issues you care about, and report any new issues in GitHub https://github.com/KantaraInitiative/wg-uma/issues Or feel free to send notes to the list or to me privately if you like, and I can collate them. We will discuss everything this Thursday.

I think we should probably take the time to continue our review through to Sep 10 if we feel at all rushed, or want to see complete new renditions. This is because, once we exit the 45-day Public Review period, we can no longer make technical changes without going back to square 1. We should be quite sure we’re happy with these drafts when they go into review. (Luckily, I no longer have a conflict with our Sep 10 meeting.)

Here are some items that we already know need editing, discussion, or review:

Don’t forget that there is new wording for permission ticket lifecycle management as discussed last week, which needs your review. See Core Sec 3.2.2.

Our new wording in response to #161, Protocol assumes one resource owner per URL https://github.com/KantaraInitiative/wg-uma/issues/161, says “When a client attempts access to a presumptively protected resource without an RPT,...”. This appears one place in RSR, where I changed “an RPT” to “an access token” and added an [UMA] cross-reference. But in the Core spec, should it say “an access token” generically?

Maciej and I discussed some questions he had around the RSR security considerations, in RSR Sec 4. What does a “valid web page” (a phrase that came from OAuth’s version) mean? I also recently added a new issue #185, RSR user_access_policy_uri: security considerations https://github.com/KantaraInitiative/wg-uma/issues/185, that may have us tweak that section a little further if we think it has merit.

I actually implemented issue #179, Use OIDC specification style of providing a subsection for every type of response https://github.com/KantaraInitiative/wg-uma/issues/179 and restructured Core so that every request and response has its own subsection — couldn't resist. :-) Of course, this meant major structural changes! Mostly I rearranged existing text, but I did end up having to rewrite section introductions and invent new introductions. And because Section 3 has a flow to it, I redid how the “flow chart” feel of the entire section works. Now the organization is a bit flatter (there is one bug I’d like to fix, which is that Core Sec 3.3-3.5 should actually be subsections in a single Sec 3.3), and each main subsection contains a consistent “how you got here” intro (and no outro). E.g.: “If the client's request at the protected resource has no RPT, or an invalid RPT or insufficient authorization data associated with the RPT as determined through RPT status checking (see Section 3.6), then assuming the resource server chooses to respond to the client,…”

Thanks in advance, all, for your review and attention.

Eve

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com mailto:xmlgrrl@gmail.com

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com mailto:xmlgrrl@gmail.com

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

Maciej Machulak

10:06 p.m.

Eve, I would also clarify what a "valid access token" means. Bear in mind that a token can be valid but may not have the necessary permissions for this resource, right? Cheers, Maciej On 2 September 2015 at 02:47, Eve Maler wrote:

...

Maybe one more while I’m at it:

Inspired by Farazath’s recent question; the discussion and resolution of #163/#164/#168 concluding that the RS has quite a lot of HTTP status discretion; and this wording in Core Sec 3.5... *“assuming the resource server chooses to respond to the client, it MUST give access to the desired resource”* , I’m thinking we should reassess old issue #15: Must the host [RS] give access if the requester [client] has suitable permission? https://github.com/KantaraInitiative/wg-uma/issues/15.

At the time, we resolved it with softer wording https://github.com/KantaraInitiative/wg-uma/commit/57aee439865aafffe33e77da4... than we have now — *“When a requester presents a valid access token, the host SHOULD provide the requester with access to the desired resource. Note that that access to resources at a host remains at the discretion of the host, even in cases where the requester has presented a valid access token."* — but we apparently never published the softer wording as an I-D, and undid the decision by rev 03 https://tools.ietf.org/html/draft-hardjono-oauth-umacore-03.

I remember that we discussed just keeping MUST because there’s nothing UMA can do about the RS’s actions, but it may make sense to be clear to RS developers and deployers that UMA is “discretionary access control”, and an RS always has the right to refuse service (so to speak), same as an authentication RP.

Eve

On 1 Sep 2015, at 9:34 AM, Eve Maler wrote:

Labor of love. :-) By the way, a couple of more editing/discussion/review items for this thread:

- Our two IETF I-Ds from the Recommendation versions of the specs (Core https://tools.ietf.org/html/draft-hardjono-oauth-umacore-13, RSR https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06 expire on Oct 6. We haven’t yet concluded our newly reopened discussion about the IETF Independent Submission/Informational RFC route, but I suspect it’s a good idea to keep updating the I-Ds for now, since, why not…?

- There’s a minor structural edit I’d like to make to Core Sec 3.6 and 3.6.1, to consolidate more of the token introspection info from the introduction into the subsection.

Eve

On 1 Sep 2015, at 8:27 AM, Maciej Machulak wrote:

Eve,

Thanks for all the work towards this draft!!!

Maciej

On Tue, 1 Sep 2015 16:25 Eve Maler wrote:

...
I have attached HTML versions of the specs for you review. (I’m not posting them on the site, so that nobody gets the idea they’re finished/vetted.) Many thanks to Maciej for working on a fresh Kantara-specific XSLT transformation! His work isn’t complete, so there are a few formatting/front page things yet to do; don’t worry about those.

Everybody please review these formatted specs carefully for ALL the issues you care about, and report any new issues in GitHub https://github.com/KantaraInitiative/wg-uma/issues Or feel free to send notes to the list or to me privately if you like, and I can collate them. We will discuss everything this Thursday.

I think we should probably take the time to continue our review through to Sep 10 if we feel at all rushed, or want to see complete new renditions. This is because, once we exit the 45-day Public Review period, we can no longer make technical changes without going back to square 1. We should be quite sure we’re happy with these drafts when they go into review. (Luckily, I no longer have a conflict with our Sep 10 meeting.)

Here are some items that we already know need editing, discussion, or review:

- Don’t forget that there is new wording for permission ticket lifecycle management as discussed last week, which needs your review. See Core Sec 3.2.2.

- Our new wording in response to #161, Protocol assumes one resource owner per URL https://github.com/KantaraInitiative/wg-uma/issues/161, says *“When a client attempts access to a presumptively protected resource without an RPT,...”*. This appears one place in RSR, where I changed *“an RPT”* to *“an access token”* and added an [UMA] cross-reference. But in the Core spec, should it say *“an access token”* generically?

- Maciej and I discussed some questions he had around the RSR security considerations, in RSR Sec 4. What does a “valid web page” (a phrase that came from OAuth’s version) mean? I also recently added a new issue #185, RSR user_access_policy_uri: security considerations https://github.com/KantaraInitiative/wg-uma/issues/185, that may have us tweak that section a little further if we think it has merit.

- I actually implemented issue #179, Use OIDC specification style of providing a subsection for every type of response https://github.com/KantaraInitiative/wg-uma/issues/179 and restructured Core so that every request and response has its own subsection — couldn't resist. :-) Of course, this meant major structural changes! Mostly I rearranged existing text, but I did end up having to rewrite section introductions and invent new introductions. And because Section 3 has a flow to it, I redid how the “flow chart” feel of the entire section works. Now the organization is a bit flatter (there is one bug I’d like to fix, which is that Core Sec 3.3-3.5 should actually be subsections in a single Sec 3.3), and each main subsection contains a consistent “how you got here” intro (and no outro). E.g.: *“If the client's request at the protected resource has no RPT, or an invalid RPT or insufficient authorization data associated with the RPT as determined through RPT status checking (see Section 3.6), then assuming the resource server chooses to respond to the client,…”*

Thanks in advance, all, for your review and attention.

Eve

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

-- Maciej Machulak email: maciej.machulak@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL)

Eve Maler

2 Sep 2 Sep

12:01 a.m.

Yes, that wording is pretty old; we’d have to modernize it if we’re interested in it. Basing it on the wording we have now, it could be something like: "If the client's request at the protected resource has a valid RPT associated with sufficient authorization data as determined through RPT status checking (see Section 3.6), then assuming the resource server chooses to respond to the client, it SHOULD provide access to the desired resource. Reasons for not providing access include, for example, a need to apply additional application-specific security checks.” Since a SHOULD should always be accompanied by a rationale for not following the SHOULD, giving this example seems apt. (And since it’s security-related, it sort of harks back to the statement in the intro that “The recipient of each request message SHOULD respond unless it detects a security concern…”.) Also note that since the RS is in total control of when it starts using the UMA header in responses, it could apply "application-specific security checks” before starting the UMA dance and we’d be none the wiser. Eve p.s. I believe that this entire idea falls into the same category of patch-release logic as the rest of the #163/#163/#168 discussion. :-)

...

On 1 Sep 2015, at 7:06 PM, Maciej Machulak wrote:

Eve,

I would also clarify what a "valid access token" means. Bear in mind that a token can be valid but may not have the necessary permissions for this resource, right?

Cheers, Maciej

On 2 September 2015 at 02:47, Eve Maler mailto:eve@xmlgrrl.com> wrote: Maybe one more while I’m at it:

Inspired by Farazath’s recent question; the discussion and resolution of #163/#164/#168 concluding that the RS has quite a lot of HTTP status discretion; and this wording in Core Sec 3.5... “assuming the resource server chooses to respond to the client, it MUST give access to the desired resource” , I’m thinking we should reassess old issue #15: Must the host [RS] give access if the requester [client] has suitable permission? https://github.com/KantaraInitiative/wg-uma/issues/15.

At the time, we resolved it with softer wording https://github.com/KantaraInitiative/wg-uma/commit/57aee439865aafffe33e77da4... than we have now — “When a requester presents a valid access token, the host SHOULD provide the requester with access to the desired resource. Note that that access to resources at a host remains at the discretion of the host, even in cases where the requester has presented a valid access token." — but we apparently never published the softer wording as an I-D, and undid the decision by rev 03 https://tools.ietf.org/html/draft-hardjono-oauth-umacore-03.

I remember that we discussed just keeping MUST because there’s nothing UMA can do about the RS’s actions, but it may make sense to be clear to RS developers and deployers that UMA is “discretionary access control”, and an RS always has the right to refuse service (so to speak), same as an authentication RP.

Eve

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

3305

Age (days ago)

3306

Last active (days ago)

List overview

Download

5 comments

2 participants

participants (2)

Eve Maler
Maciej Machulak