This HTML5 document contains 304 embedded RDF statements represented using HTML+Microdata notation.

The embedded RDF content will be recognized by any processor of HTML5 Microdata.

PrefixNamespace IRI
xhvhttp://www.w3.org/1999/xhtml/vocab#
foafhttp://xmlns.com/foaf/0.1/
awolhttp://bblfish.net/work/atom-owl/2006-06-06/#
pwdrhttp://www.w3.org/2007/05/powder-s#
dchttp://purl.org/dc/elements/1.1/
n18http://ods-qa.openlinksw.com:8896/sparql/
schemahttp://schema.org/
rdfshttp://www.w3.org/2000/01/rdf-schema#
prvhttp://purl.org/net/provenance/ns#
n25https://forum.solidproject.org/stylesheets/desktop_2_4bbe344fda4442c21782097348aff0aa74cd627a.css?__ws=forum.solidproject.
n11http://ods-qa.openlinksw.com:8896/about/id/https/forum.solidproject.org/t/registering-paying-users-for-a-web-app/
opltwhttp://www.openlinksw.com/schemas/twitter#
voidhttp://rdfs.org/ns/void#
n12twitter:
n26https://forum.solidproject.org/stylesheets/desktop_theme_3_e9ac9dd10656bde3b5a84e2bd6225bc05beb187f.css?__ws=forum.solidproject.
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#
n20https://forum.solidproject.org/uploads/default/original/1X/01a386335cb8f59349567d7e6dab472bf15e57d3.
owlhttp://www.w3.org/2002/07/owl#
n6http://ods-qa.openlinksw.com:8896/about/id/entity/https/forum.solidproject.org/t/registering-paying-users-for-a-web-app/
n24https://forum.solidproject.org/opensearch.
n4http://ods-qa.openlinksw.com:8896/proxy-iri/
mdhttp://www.w3.org/1999/xhtml/microdata#
n2https://forum.solidproject.org/t/registering-paying-users-for-a-web-app/
n9https://forum.solidproject.org/t/registering-paying-users-for-a-web-app/480#
n16https://forum.solidproject.org/t/registering-paying-users-for-a-web-app/480.
xsdhhttp://www.w3.org/2001/XMLSchema#
siochttp://rdfs.org/sioc/ns#
n22https://forum.solidproject.org/uploads/default/original/1X/8b03012bca25b9b7492f933b6d9eb44eb31a12c2.
Subject Item
n4:d98e39cddd982df5121dc0d3c19fb5f5e4c76579
rdf:type
rdf:Statement
rdfs:label
Embedded JSONLD-in-HTML Statement 16
pwdr:describedby
n11:480 n6:480
rdf:object
n4:14479c01b9cb911916acef0c20b139c8504d2767
rdf:predicate
schema:potentialAction
rdf:subject
n2:480
Subject Item
n4:6f3c2bca29421d55dfe04ad67dfdbb8c59eb6642
rdf:type
rdf:Statement
rdfs:label
Embedded JSONLD-in-HTML Statement 17
pwdr:describedby
n6:480 n11:480
rdf:object
https://forum.solidproject.org
rdf:predicate
schema:url
rdf:subject
n2:480
Subject Item
n4:9ec6d19de4a1ed3586e37a2aab1e3a1e949d325f
rdf:type
rdf:Statement
rdfs:label
Embedded JSONLD-in-HTML Statement 18
pwdr:describedby
n6:480 n11:480
rdf:object
n2:WebSite
rdf:predicate
rdf:type
rdf:subject
n2:480
Subject Item
n4:e13d09cb60bf1786cc598566cc10e02f481a2010
rdf:type
rdf:Statement
rdfs:label
Embedded JSONLD-in-HTML Statement 19
pwdr:describedby
n11:480 n6:480
rdf:object
n2:480
rdf:predicate
prv:accessedService
rdf:subject
_:vb734547
Subject Item
n4:a44c3562a32cde71d2f0c251cfb006915cbd53a6
rdf:type
rdf:Statement
rdfs:label
Embedded JSONLD-in-HTML Statement 20
pwdr:describedby
n11:480 n6:480
rdf:object
2019-11-20T12:48:52.010632
rdf:predicate
prv:performedAt
rdf:subject
_:vb734547
Subject Item
n4:22d623bd588809a7f04572e9c522dd5002167b83
rdf:type
rdf:Statement
rdfs:label
Embedded JSONLD-in-HTML Statement 21
pwdr:describedby
n6:480 n11:480
rdf:object
n9:spongerInstance
rdf:predicate
prv:performedBy
rdf:subject
_:vb734547
Subject Item
n4:b228168eb3b5bba3b895fec2b6fcdfda1c76d81b
rdf:type
rdf:Statement
rdfs:label
Embedded JSONLD-in-HTML Statement 22
pwdr:describedby
n6:480 n11:480
rdf:object
prv:DataAccess
rdf:predicate
rdf:type
rdf:subject
_:vb734547
Subject Item
n2:480
rdf:type
n2:WebSite schema:CreativeWork
owl:sameAs
n9:this
pwdr:describedby
n11:480
foaf:topic
n4:96277e0008e5880abe15014ebc4dbcc3f9671cc6 n4:30efbe44695ecd44a42b559e707d810d54ed8721 n4:2789c8ad483bb7784df0d98a46394d91147c0d9b n4:91a655ed6d9e83190884d3383ac1cdfd8de7091c n4:e98e9bf36274162d3a6c60a441ceb8f83bf2a2dc n4:0d59aa8ce3257249e6fbce4d81a804dedf0474ca n4:940e48162f5507919bfb19d0dc295ab972c2f6a2 n4:fcbdc034ffd8ca7c346d5786c29d26cfff1b5360 n4:4cb9ed7d27cbe8a79c5933dd768e3ac10fce39a5 n4:51ee00641a7f6ab75467c8d040a9099a1d2ce70f n4:2505b3703f40e566df3c021b8e562474fb3e1cb9 n4:f0cf7399e4cc7c8697e16d5d34657bb7a48e1c3a n4:fb96a6764d427b1284df9507145206caf254aeed schema:headline n4:9c362c0d07c4847f25bf71350d6781567ca9f5a3 n4:2659a8832e162423f528579e84111c730ccdd12b n4:1018455424c675ce7d47351a68e97682dda6dc66 n4:ecff3428587855149e207af8d110e2eb37eecf72 n4:dab6050d435b7b3af919d1b66122ba7675290aa5 n4:89f44cd308e5ec4eaa512676366052c9b24f1ba9 n4:89a5c661394bc7776e92ea1b243180d56770122a n4:0646293a5e8504f80b2baee13e10d6a8595a162c n4:a2ca28cfc5b4a7c71db98601631a379061bdd313 n4:b23ba9212323c337b5c54f26effbbf2a7bdd55c2 schema:interactionCount _:vb734547 _:vb734544 n4:2270e05fba47047546db507bc2665ebd27dc676c n4:4aad35ad3561b3056147516fb6a74836f531de99 _:vb734550 n4:14479c01b9cb911916acef0c20b139c8504d2767 n4:289a2e73066073fea86321af04c901178c464267 _:vb734551 n4:41405b2a54ecf620ca9a6dde88db6c343ea95e54 _:vb734548 n4:b54fca6f7ee1b3905aea5051395c622d68ab894e _:vb734549 n9:this n4:dcd7b2ce4cf954a7b5b001720d2d8f469d797da7 n9:rdf_load_json n4:0987f4cce528fd89e57effb6ef8b765bfbf02c51 n4:4e6b741c12172cef56c86fd4113100328ba4cc96 n4:5cee5d186805c7b3b745c5a29ecf46d66cf0f013 n9:DataCreation n4:44af80d5b34d934f46666aebc85092ced39a9c2b n4:b733e1f1c3dfec5f9f0a82d0729ce1ddc42f0e7a n4:8f2d189ffead7ebc80da0491553292fd3ecf3a47 n4:2ad998430a5409889be7ed80c679cf7b598bdca7 n4:c75f44a6e87cf2f3775f5614e7d6bca4cf2cb829 n4:0402fefd34c7f0ef428a5f77fc785aa0dd526f3e n4:c4ee03617cdced9e4845647719fcd54be6157bcd n4:6ee65cd36c8a80dde9f0697d45553f5a2050aa67 schema:datePublished n4:ccbbf35f9e0d9208115232e1044bd3b17a876dee n4:65c9aec9490b2f2e518eae40cbb9293eee68ada8 n4:9b43f77c6419b97d09fd935758d7e149f32020be _:vb734542 _:vb734543 awol: xhv: n4:74010edec1429084e933a1b5015d279293ad78bc n4:f911017851893a68ecaf4ec62b6098b472154a5e n4:887d08b98e2ea6fac67b8b51a38e4b78478c94ca n4:0ab7ac4895a5be5fa08146e0e95517b0a174a5fa n4:00dc08f0b436cdb89bba1716b348626baccd488d n4:0f81abbac208983690cafb8f7d531f8233faf8bc n4:f1e9fabe9aaa006c73beb9a51eea928291b2e3e5 n4:76e78dd295f19e5120b4d3fb6728dfbbf48f8981 n4:032bffe6b428515e56c3e885464917ad00613b62 n4:565ad5ab67252eeb695ed44fe63addf33d2358e9 n4:ee4b57d8dd323d76436f40c5e66a5ce9eeeb8b0d n4:14e2a321aef4d00e05f7580bcc4be0c648257611 schema:articleBody n4:4bd7b7c8d48b686aee560e6c324042144a0af8f5 n4:289929bc66d9227007385a88f38bfe49cb6afe8c n4:03ad500e685eac7e9e75d00ad3d7487838d10b6f n4:18a9c3a443f80b1dab6c227b648f7ca54488fadb n4:200f108077e8b9d59324a25c4560c261f0dc49af n4:12b2afb210c008448522bc2f6c3c9783fcc7d02d n4:49c4f8e5cacc4454d2f4182cd6d52948e4cd9a2c n4:f6048f96ba30fe3cad2b5f16e06b9f19552da152 n4:05e7c8102e3851fbaca72b68b922d26c33fdff51 n4:fbf20415ac8c02e973d98015f9f47a78611c96e2 n4:506d57b5be027b592297a771fab3d0397f7613f7 dc: n4:8f00c6a7c96dbc55a52fe80f4de654f70fe6aa24 n4:6d64547f2db1680818ef5c35346c78c3093c3ed0 opltw: n4:2f2834f7cfd26ac02080e57a1b536e99edc7d913 n4:757769df84568b2e16b375b1742318ea7e1e6598 n4:d98e39cddd982df5121dc0d3c19fb5f5e4c76579 n4:9ad9d79532b87a71ce147929b44fcb602a605784 n4:178c71009d0e343879ea6bf1ab02635d4fd0134d n4:6f3c2bca29421d55dfe04ad67dfdbb8c59eb6642 n4:9ec6d19de4a1ed3586e37a2aab1e3a1e949d325f n4:376191290f929269bd68a6a511bbd7bf918a5e96 n4:bad8e8db6d7952f0f840070362996443fe81687a n4:db7cf60d4a433700bae51eaa71b13f3cb8d85f87 n4:6f83bf3afa7820cf57b6f6cecfe12dcfd05c6816 n4:277defd1b312d9c126e98ffac51c235da859551c n4:684f90327d36dee5ccb090ecfcaa95c9c0cf4024 n4:25e1a0b1c30992291772a9e9d2b6814cbd54f37a n4:d37a20da62ebb13d3596b69c331be913ff7e12de rdfs: n4:352059eba51977519d3b5d4238c444a8cb55cbdc foaf: n4:43cfffa11ee3bb1ce79098075bedcfb3fa0aacb2 n4:56f9a69b12e32dca9c0d1ad13a9fa0249790b87b rdf: n4:98304dd663eae4bd0ff4b67507adda45b0b0c11b sioc: n4:b38d38866cbc5f48cb5cecda25955deac29df622 n4:05dd8e9ef1799f340a43f7ee2b7efbe24bb65324 n4:8daaa3952aa87d1ab936237885f6d6263fc31332 n4:392c140470f67f76946d5727e65c348deddb282a n4:2c3f413a1def1c7577ea424dbde3a103cba5fe0a n4:316408060ca257c0712ebf01a0baa98b25ab121f n4:55aea5cb2002194b78601b7b4712104869686ae5 n4:36d1671cf055d3a2664fc4acaa63cd757505fc40 schema:author n4:be79519d0108aecbbefd7f42294f5004cc052057 n4:8d7e5848bd7f0da90bf5a7f4872e81683b668a6a n4:4d3aeb327f52dd1f111e86b6fb1bdb7e7c3851c8 n4:7bdf4648fb44014909e326f8436edbbb3c30f870 n4:220753a919b806b6a7f364050daae454ff24b078 n4:506a2da7f479ce25a6496f66c4320e8b5190464b schema:position n4:5c0c95ef7c172daa81420eea3da27bea3d0fa412 n4:02ebfd3da38f45e46c11237fb9fa60f7d6cb0304 n4:4548b2a613be49f2b20beafdd924f251ae823325 n4:e3313d83301c972d72e5cec86b9c42de490fc122 n4:2c66374ca0c5a54afd991ffb98f8653609adcfc6 n4:25aecf204cd3c4b75729d2348290c878173b60a1 n4:52dce998503159c6273936d9a7d93015a258ce8d n4:221f8b2cc735ee93afb4bc3d23aee4b409d653cb n9:rdf_load_htmlvxc_provenance n4:9cb2e08bd85c5850d0a4d218d93f7f620edaa1ec n4:9ead235f8729d39525e1433544545e3de5baa9b9 n4:9c587984150a7b7ccfea6dc24a6cc5e1133473db n4:22d623bd588809a7f04572e9c522dd5002167b83 n4:b228168eb3b5bba3b895fec2b6fcdfda1c76d81b n4:e13d09cb60bf1786cc598566cc10e02f481a2010 n4:a44c3562a32cde71d2f0c251cfb006915cbd53a6 n4:49204d70bec6540fdbfbec6444632c8d762dd17a n4:fd2d0865181cfd86f29ae04d4cd9de5cd2170dfd n4:6f52d652beced42ac3e61e90171f34c84216b3d6 n4:0380d84b57aed4e45ef39be9d7fc55c9134dda2f n4:b8e72bb43e5950d8e2c24e435c2147b13c6f8b75 n4:bca89387cbda1693c0e389ad07f3d2ea18831cce owl: n4:f4836ebcb11d84a1ff8b5f8139240ec4f72adf45 n4:8da47c163705f499f7bc18f895b0adaf487b80f2 n4:96a52a52363529deb781f9d074f0491cd89f8651 n4:ad4189326bedc3b969f440da8932ae2556d8bbc4 n4:444b4678c75945db01ccb41a276f271d090bf651 n4:4402270a62db44be8630a1a5c78a65653d1dd7d5 n4:2b3c5a47d3a340b4bee5432fc67de41ad40e984b n4:f199e563107e742b8b74095437c3ebbfd9df8366 n4:8f612917ab34730ac2e1880bc67e4d53dee7b66a n4:3b86bc5a2eb8fb05a64d580aaa934173d9c6a791 schema: n4:c53bd80d7e7f523d65cc898b0c98d07fa2ba49d9 n4:348b4723eed472bc7f7592d423cb8e41025de668 n4:9a70063964e5481ad1cdc0bc520d12e192c97809 n4:9f6e9fa341442c3803b1e2fedc0f2efc7c2fddb2 n4:67a46c69f58ed8ee288dc9c27e4db6415c31dba4 n4:83cc523359c758ddf641b5ed9765598bb706c934 n4:be24404dd01f06913d1a409622c27802fd8d5342 n4:b4e609ada837255a630b7112cdcc97e8d0140573 n4:adf7b1833420b4de82764f2e7d18857f0aff2eb6 n4:a93142594864b151589d6f925a6a3d5b0662f60a
schema:mainEntity
n6:480
schema:potentialAction
n4:14479c01b9cb911916acef0c20b139c8504d2767
md:item
_:vb734544 _:vb734550 _:vb734551 _:vb734549 _:vb734542 _:vb734543
n12:card
summary
n12:description
Usually, when I go to some sort of web-application provider, I must create a login/account with them and register to user their paid services. But with Solid we expect users to authenticate with thier WebId, meaning users already have an account elsewhere - do we then want them to create yet another account for the specific web-application? Potentially meaning they need to login twice to access the service? It seems to me that there should be an easy-to-use standard Solid way of linking accoun...
n12:image
https://forum.solidproject.org/uploads/default/original/1X/01a386335cb8f59349567d7e6dab472bf15e57d3.png
n12:title
Registering paying users for a web-app
n12:url
https://forum.solidproject.org/t/registering-paying-users-for-a-web-app/480
void:sparqlEndpoint
n18:
schema:url
n2:480 https://forum.solidproject.org
n2:alternate
n16:rss
n2:apple-touch-icon
n20:png
n2:author
n2:canonical
n2:480
n2:description
Usually, when I go to some sort of web-application provider, I must create a login/account with them and register to user their paid services. But with Solid we expect users to authenticate with thier WebId, meaning use…
n2:generator
Discourse 2.2.0.beta4 - https://github.com/discourse/discourse version c27502793901767d584f28e254caa7de000363c2
n2:icon
n22:png
n2:search
n24:xml
n2:stylesheet
n25:org n26:org
n2:theme-color
#ffffff
n2:viewport
width=device-width, minimum-scale=1.0, maximum-scale=1.0, user-scalable=yes
Subject Item
_:vb734542
rdf:type
http://schema.org/DiscussionForumPosting
author
pwdr:describedby
n6:480
articleBody
Usually, when I go to some sort of web-application provider, I must create a login/account with them and register to user their paid services. But with Solid we expect users to authenticate with thier WebId, meaning users already have an account elsewhere - do we then want them to create yet another account for the specific web-application? Potentially meaning they need to login twice to access the service? It seems to me that there should be an easy-to-use standard Solid way of linking accounts, such that the web-app service provider can detect a new login from a WebId, inform the user immediately that they are newcomers to the service and would they, please, fill-out the payment details (or select the free plan), fetch as much information as possible from the WebId profile, and then automatically link the WebId account with their own automatically generated account. Maybe this is all well-known, but perhaps it was worth having this kind of workflow well defined in the Solid “best practice” documentation.
headline
Registering paying users for a web-app
position
#1
datePublished
interactionCount
UserComments:0 UserLikes:1
Subject Item
_:vb734543
rdf:type
http://schema.org/DiscussionForumPosting
author
pwdr:describedby
n6:480
articleBody
This raises another question - in order to allow the web-app’s server to link the WebId with some internal account, the web-app/browser must be able to prove it’s WebId to the server. Unfortunately the server was never involved in the login process which is strictly confined to the browser and the web-app’s javascript code, so the server has no knowledge of that process. The web-app cannot simply POST it’s WebId to the server since anybody else would be able to do the same with any WebId they wanted. Neither can the web-app build a signed OpenID Connect token to POST as the signing key would be available to anyone that can read the javascript code. So how does the web-app / browser-javascript-code prove the WebId it received to the server it is served from? Is there any token of some sort the web-app can send to the server and allow it to validate it with the remove WebId identity provider?
headline
Registering paying users for a web-app
position
#2
datePublished
interactionCount
UserComments:0 UserLikes:0
Subject Item
_:vb734544
rdf:type
http://schema.org/SiteNavigationElement
pwdr:describedby
n6:480
Subject Item
_:vb734547
rdf:type
prv:DataAccess
pwdr:describedby
n6:480 n11:480
prv:performedAt
2019-11-20T12:48:52.010632
prv:performedBy
n9:spongerInstance
prv:accessedService
n2:480
Subject Item
_:vb734548
rdf:type
prv:DataAccess
pwdr:describedby
n11:480 n6:480
prv:performedAt
2019-11-20T12:48:52.010632
prv:performedBy
n9:spongerInstance
prv:accessedService
n2:480
Subject Item
_:vb734549
rdf:type
http://schema.org/DiscussionForumPosting
author
pwdr:describedby
n6:480
articleBody
Usually, when I go to some sort of web-application provider, I must create a login/account with them and register to user their paid services. But with Solid we expect users to authenticate with thier WebId, meaning users already have an account elsewhere - do we then want them to create yet another account for the specific web-application? Potentially meaning they need to login twice to access the service? It seems to me that there should be an easy-to-use standard Solid way of linking accounts, such that the web-app service provider can detect a new login from a WebId, inform the user immediately that they are newcomers to the service and would they, please, fill-out the payment details (or select the free plan), fetch as much information as possible from the WebId profile, and then automatically link the WebId account with their own automatically generated account. Maybe this is all well-known, but perhaps it was worth having this kind of workflow well defined in the Solid “best practice” documentation.
headline
Registering paying users for a web-app
position
#1
datePublished
interactionCount
UserLikes:1 UserComments:0
Subject Item
_:vb734550
rdf:type
http://schema.org/DiscussionForumPosting
author
pwdr:describedby
n6:480
articleBody
This raises another question - in order to allow the web-app’s server to link the WebId with some internal account, the web-app/browser must be able to prove it’s WebId to the server. Unfortunately the server was never involved in the login process which is strictly confined to the browser and the web-app’s javascript code, so the server has no knowledge of that process. The web-app cannot simply POST it’s WebId to the server since anybody else would be able to do the same with any WebId they wanted. Neither can the web-app build a signed OpenID Connect token to POST as the signing key would be available to anyone that can read the javascript code. So how does the web-app / browser-javascript-code prove the WebId it received to the server it is served from? Is there any token of some sort the web-app can send to the server and allow it to validate it with the remove WebId identity provider?
headline
Registering paying users for a web-app
position
#2
datePublished
interactionCount
UserLikes:0 UserComments:0
Subject Item
_:vb734551
rdf:type
http://schema.org/SiteNavigationElement
pwdr:describedby
n6:480